Jer Lang

Division of Computer Science and Information Technology University Of Nottingham, Malaysia Campus
UG FINAL YEAR DISSERTATION REPORT
- David War Game -
Students name: Hong Jer Lang Students Number: UNIMKL-000170 Supervisors Name: Mr. Nasreddine Hallam Year: 2004/2005
SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE AWARD OF BACHELOR OF SCIENCE IN COMPUTER SCIENCE SINGLE ( HONS ) THE UNIVERSITY OF NOTTINGHAM MALAYSIA CAMPUS
- David War Game -
Submitted in May 2005, in partial fulfillment of the conditions of the award of the degrees B.Sc.
- Jer Lang Hong Division of Computer Science and Information Technology University of Nottingham Malaysia Campus
I hereby declare that this dissertation is all my own work, except as indicated in the text:
Signature ________________________ Date 04/05/2005
Division of Computer Science and Information Technology University of Nottingham Malaysia Campus
UG FINAL YEAR DISSERTATION FINAL REPORT
Title: David War Game Version: X11 Beta 2

Name: Hong Jer Lang ID: 495 Supervisor: Mr. Nasreddine Hallam Course: Computer Science Year: 3 Division: CS&IT Date: 23/10/2004
David War Game Final Report Final Year Project 2004/05
Acknowledgements:
First of all, I would like to thank my family members, especially my parents and my brother for giving me encouragement and support throughout the course of the project. I would like to express my sincere thanks to my father who gave me advices and suggestions, for the work I had done. I would also like to take this opportunity to express my sincere thanks to my supervisor, Mr. Nasreddine Hallam, for giving me guidance and support throughout the course of the entire project. He had contributed a lot in the successful completion of this project. Mr. Hallam had been continuously giving me suggestions, evaluating the progress of the work and providing valuable comments on the program that I had developed. I am also indebted to my friends, particularly Mr. Qiao Yiming, Miss Huang Li Wen, and Mr. Lim Shuh Chuan for giving me support, guidance, motivation and advice throughout the project. They played a major role in the Beta Testing Phase of the project, which ended up successfully in the development of the final working David War Game.
Thank you, David Hong Jer Lang, David War Game, 3rd Year, CS, CS&iT, University of Nottingham in Malaysia
David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
ii
Contents:
Acknowledgements Content Page
Part I: Introduction
Chapter 1: Introduction and overview
1.1 : Abstract 1.2 : Historical background 1.3 : Introduction 1.4 : Motivation for the project 1.5 : Aim 1.6 : Area/Scope 1.7 : Objectives 1.8 : Methodology 1.9 : Software/Hardware requirement 1.10: Feasibility study 2 3 4 6 7 7 8 9 11 15
Part II: Analysis and Design

Chapter 2: Problems, Studies, and Requirements For The New System
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 : Overview : Problems : Studies on some games of the current system : Related Works : Requirements of the new system : Task Management : Literature review : Pseudo code : The Design Structure of David War Game 17 18 21 26 29 30 32 35 41
iii
Chapter 3: Requirement Analysis For The Proposed System 3.1 : Core unit and structure of the program
3.1.1 3.1.2 3.1.3 : Memory : Speed : Components 45 45 46
3.2 : UML As A Modeling Tool For The Proposed System

3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 : Use case diagram : State diagram : Management diagram : Class diagrams : Context diagrams 47 48 49 50 64
3.3 : Requirement Specification

3.3.1 3.3.2 : Non functional requirements : Functional requirements 77 78
3.4 : Some sample UI of the proposed System

3.4.1 3.4.2 3.4.3 3.4.4 : Menu : 2D Game : 3D Game : Miscellaneous 80 81 82 82
3.5 : Design Choices for David War Game

3.5.1 3.5.2 3.5.3 : Do and dont : Current design methods in society : David War Game Design 83 84 84
iv
Part III: Implementation

Chapter 4: General Game Design
4.1 : How The Program Works: Thread Processing 4.1.1 4.1.2 4.1.3 : Java Threads : Synchronization : Threads Methods 86 87 87
4.2 : The Multimedia Aspect of The New System 4.2.1 : Audio 4.2.1.1 : Player 4.2.1.1.1 4.2.1.1.2 4.2.1.1.3 4.2.1.1.4 : MP3 Player : WAV Player : MIDI Player : Other Players 88 88 88 87 89 89
4.2.1.2 : Decoder 4.2.1.3 : Converter 4.2.2 : Video 4.2.2.1 : MPEG Player 4.2.2.2 : The JMStudio 4.2.2.3 : License 4.2.2.4 : The Freeware Sure Player 4.3 : General Design Structure of The 2D And 3D game 4.3.1 : 2D Game 4.3.1.1 : Memory management 4.3.1.2 : Component 4.3.1.3 : Sound and Video 4.3.2 : 3D Game 4.3.2.1 : Memory management 4.3.2.2 : Component 4.3.2.3 : Sound and Video 4.3.2.4 : The DX 3D Engine David Hong Jer Lang Computer Science Year 3 CS&iT UNiM v
90 90 91 91
92 93 93
94 95 95 96
David War Game Final Report Final Year Project 2004/05 4.4 : UI Design 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 : Background Images : Buttons : Sound Effects : Animation : Other Components : Key and Mouse Handling : The Library Menu : Discussion on several developed UI: 4.4.8.1 : About menu 4.4.8.2 : Loader menu 4.4.8.3 : Configuration menu 99 99 100 100 100 101 101
103 104 105
Chapter 5: 2D Game Design

5.1 : Single Player Game Design 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.2 : Memory unit : UI : Player : Enemy : Map : Tile and Collision Detection 106 107 107 108 109 110
: Extension to Online And Multiplayer Gaming 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 : Overview of the Multiplayer Game Concept 112 : Studies on Multiplayer Game Concept 113 : Implementation on David War Game 114 : Java NIO interface 114 : Implementation on J2ME technologies and devices114
vi
Chapter 6: Graphics and Environment in 3D Game

6.1 : Graphics in 3D 6.1.1 6.1.2 : Basics of Graphics : Math Fundamental 6.1.2.1 : Vector 6.1.2.2 : Matrices 6.1.2.3 : Transformation 6.1.2.4 : Normal 6.1.2.5 : Coordinates and vertices 6.1.3 6.1.4 6.2 : Polygon Structure : Camera View 115
116 116 117 120 120 121 121
: Texture Mapping and Lighting 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 : Overview on Texture Mapping And Lighting : Simple lighting : Advanced lighting with shadow effect : Several concepts for lighting : Concept of Texture Mapping 123 124 125 125 126
6.3
: Objects in 3D 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 : Definition of an Object : Format for OBJ file : GameObject class : Animation : Polygon Group Concept : Parser for OBJ file : Objects in David War Game 6.3.7.1 : Normal Objects 6.3.7.1.1 6.3.7.1.2 6.3.7.1.3 : Crate Boxes : Health Boxes : Ammo Boxes 140 140 141 128 128 129 134 135 137
6.3.7.2 : Enemy Objects 6.3.7.2.1 6.3.7.2.2 6.3.7.2.3 6.3.7.2.4 David Hong Jer Lang Computer Science Year 3 CS&iT UNiM vii : Tiger I Heavy Tank : JagdPanther Tank Destroyer : Half Track : 88 Anti Tank Gun 142 143 144 145
David War Game Final Report Final Year Project 2004/05 6.3.7.2.5 6.3.7.2.6 6.3.7.2.7 6.3.7.2.8 6.3.7.2.9 6.3.7.2.10 6.3.7.2.11 6.3.7.2.12 6.3.7.2.13 6.3.7.2.14 6.3.7.3 : Player 6.4 : Map For The Environment in 3D Game 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8 6.5 : Binary tree basis : Painters algorithm : 1D and 2D BSP Tree : Plane (3D) BSP Tree : MAP file format : Map Loader/Parser : Front to Back Principles : 2D Map Display of the Environment 157 158 159 161 162 163 165 166 : Sherman Medium Tank : T34 Medium Tank : Infantry Unit : Bazooka Team : Bunker : Z Tekken : Sturm Tiger : Panther : JS2 : Willy 146 147 148 149 150 151 152 153 154 155 156
: Unit Editor 6.5.1 6.5.2 6.5.3 : Enhanced Parser : Country, Head, and Body Features : Reuse of OBJ file 167 168 169
Chapter 7: Artificial Intelligence, Interactivity and Path Finding Among Objects in 3D Game
7.1 : Collision Detection 7.1.1 : Type of Collision Detection 7.1.1.1 : Box 7.1.1.2 : Cylinder 7.1.1.3 : Rectangle 7.1.1.4 : Object detection 7.1.2 7.1.3 7.1.4 170 171 171 172
: Object and Object Collision 172 : Object and World Collision 172 : Enhanced Collision Detection (Sliding Principle) 173
viii
David War Game Final Report Final Year Project 2004/05 7.2
: Path Finding
7.2.1 : Breadth first search 7.2.2 : Portals 7.2.3 : A* Heuristic 7.2.4 : Path Bot 176 176 177 179
7.3
: AI For The Unit in 3D Game

7.3.1 : Patterns 7.3.2 : Probability basis 7.3.3 : Evolution 7.3.4 : Unit intelligence 7.3.4.1 : Seeing 7.3.4.2 : Hearing 7.3.4.3 : Radius Detection 7.3.5 7.3.6 7.3.7 : A bots capability : Morale : Players toolbar and other objects 182 183 184
185 185 186 187 187 188
Chapter 8: Other Features in 3D Game

8.1 : Game Scripting, Plugs In, Save and Load 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 8.1.6 8.1.7 : Secret levels : Medal : Plugs In : Story Loader : Java Serialization API and Persistence State : Snap shot of Game Play : Save and Load UI 189 189 190 190 190 191 191
ix
David War Game Final Report Final Year Project 2004/05 8.2 : Weapons 8.2.1 : Infantry Weapons 8.2.1.1 : Hand Gun 8.2.1.2 : Rifle 8.2.1.3 : Sub Machine Gun 8.2.1.4 : Machine Gun 8.2.1.5 : Heavy Machine Gun 8.2.2 : Anti Tank Weapons 8.2.2.1 : Mine 8.2.2.2 : Sand Grenade 8.2.2.3 : Time Bomb 8.2.2.4 : Bazooka 8.3 : Missions in David War Game 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.3.7 8.3.8 8.3.9 8.3.10 8.3.11 8.3.12 8.3.13 8.3.14 : Mission 1 : Mission 2 : Mission 3 : Mission 4 : Mission 5 : Mission 6 : Mission 7 : Mission 8 : Mission 9 : Mission 10 : Mission 11 : Mission 12 : Mission 13 : Mission 14 198 199 199 200 201 201 202 203 203 204 205 205 206 207 195 196 196 197 192 193 193 194 194
Part IV: Testing, Problems, and Planning

Chapter 9: Alpha, Beta Phase and its role in Testing
9.1 9.2 9.3 : Bugs, issues and constraints encountered : Handling of bugs. issues and constraints : User feedback 209 213 216
Chapter 10: Future work and planning

10.1 10.2 10.3 10.4 10.5 10.6 10.7 : Work Done and Future Work : Unexpected features : Suggestion for upgrading and enhancement : Problems faced : Deployment : Maintenance : David War Game Web Page 217 219 219 219 220 221 221
Part V: Summary
Chapter 11: Summary
11.1 : The project on the whole 11.2 : Summary 11.3 : Conclusion 223 224 224
References
R1 : Books R2 : Webs R3 : Papers R4 : CDs 226 228 229 229
xi
Appendices
Appendix A: Some famous quote from the leader of World War 2 Appendix B: Personal Communication with Game Programmers Appendix C: UI of the game developed Appendix D: Initial draft Appendix E: Map drawing by level Appendix F: Unit prototype drawing Appendix G: Weapons in David War Game Appendix H: Time management Appendix I: Questionnaire and its analysis Appendix J: Description of Unit In Real World Appendix K: David War Game User Manual Appendix L: Beta Testing Analysis 231 233 236 243 247 255 301 310 311 323 335 344
xii
List of Figures:
Figure 1: RAD Figure 2: Commercial Games Figure 3: Task Management Figure 4: Game Design Figure 5: UML
5.1 5.2 5.3 5.4 5.5 : Use Case Diagram : State Diagram : Management Diagram : Class Diagram : Context Diagram 47 48 49 50 64
9 22 31 41
Figure 6: Sample UI Figure 7: General Game Design Figure 8: 2D Game Design Figure 9: Graphics and Environment in 3D Game Figure 10: Artificial Intelligence, Interactivity and Path Finding Among Objects in 3D Game Figure 11: Other Features in 3D Game
80 86 106 115 170
189
xiii
List of Tables:
Table 1: Nonfunctional Dependencies Table 2: Functional Dependencies Table 3: Enemy capability 77 78 187
xiv
List of Abbreviations:
1D: One Dimensional 2D: Two Dimensional 3D: Three Dimensional API: Application Programming Interface BSP Tree: Binary Space Partition Tree CAD: Computer Aided Design DBMS: Database Management System GB: Gigabyte GPL: General Public License GUI: Graphical User Interface IDE: Integrated Development Environment IE: Internet Explorer JLayer: Java Layer JMF 2.1.1: Java Media Framework 2.1.1 J2SE: Java 2 Standard Edition J2EE: Java 2 Enterprise Edition J2ME: Java 2 Micro Edition MB: Megabyte MIDI: Musical Instrument Digital Interface MOV: Movie MP3: Music Player 3 MPEG: Moving Picture Experts Group David Hong Jer Lang Computer Science Year 3 CS&iT UNiM xv
David War Game Final Report Final Year Project 2004/05 NIO: Network Input Output Interface OpenGL: Open Graphic Library OS: Operating System RAD: Rapid Application Development RAM: Random Access Memory ROM: Read Only Memory RPG: Role Playing Game SDLC: Software Development Life Cycle TCP/IP: Transmission Control Protocol Internet Protocol UDP: User Datagram Protocol UML: Unified Modeling Language URL: Uniform Resource Locator WAV: Wave
xvi
PART I: Introduction
By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
Chapter 1 Introduction and overview

1.1 Abstract
The final year project done by the author is entitled David War Games. The topic chosen as David War Games is merely due to the fact that the whole component of the game, e.g. Story Line is based on the true story of World War that occurred in the human history, particularly World War 1 and World War 2. The game is divided into 2 components, which were 2D game and 3D game. The 2D game is the concept of Adventure Games, mainly focused on the Mario Bros. Game Concept (A Nintendo Game). It is based on the story of a soldier who tried to fight for his nation, bringing freedom and justice, by battling against the enemy. The 2D game, however, was based on the fiction story, and a little bit unrealistic in nature. The 3D game, which will be the most important and highly needed component in the project, has been implemented based on the First Person Shooter Concept, such as the Medal of Honor and BattleField 1942 game. The 3D game is divided into a few subcomponents, which are Collision Detection, Scripting, AI, Path Finding, Map Editor, 3D Graphics, Texture Mapping and Lighting, Objects creation and Persistence Control Unit. It is to be stated that the project required to be wholly based on the War Story Concepts. However, the 2D game will look a little bit unrealistic and might be more suitable for the young players only. The 3D game, on the other hand, will probably be implemented based on the true story of World War 2, in terms of Buildings, Scenery, Weapons and the Story Line.
1.2 Historical Background

During the initial phase of the Final Year Project, the author of this report planned to make a War Game. Before the Final Year Project was started, planning into the topic and scope of the project was decided. It was agreed initially that the War Game developed will be based on the 2D concept, while the implementation of the game in 3D will be an enhanced work instead. The game was designed to have air, land and sea unit in it, such that it was like in the real life environment. The concept of the War Game will be based on Strategy concept, with a simple sound player, but no video player. Some sources of images and icons have been collected, particularly on the commercial games available on the market, such as Sudden Strike [CD8]. After a period of about a week, some game programmers around the world have offered their help in the Project. It was during this time that plan was being made on developing a more complex system, which was based on the Commercial Games, and having a 3D Environment. Thus, the Project eventually focuses on developing a 3D and 2D game, with the title chosen as David War Game. The concept of the War Game was changed to First Person Shooter instead, because this concept made full use of the 3D concept.
1.3
Introduction
The final year project chosen was David War Game. The name was given David War Game based on two reasons. First, it was a game developed by the author of this report, as a requirement for the Final Year Project. Second, it was a project about developing a Game, based on War Concept, set during the period 1939-1945, in which the World War 2 occurred. David War Game was developed based on the Real Story of World War 2, which included the wars in North Africa, Stalingrad, Britain, and France. However, due to the level of experience in the programming languages and the knowledge of War Storyline, the game was developed to be as realistic as World War 2, but there is no guarantee that the story line in the game will be the same as in the World War 2. The game consists of 2 components, the 2D game and the 3D game. The 2D game looks a little bit fictional in general. Its story line was based on the story of the game Metal Slug. It is a story of a rebel who was eager to fight his enemy for the freedom of his country. The 2D game has some aliens inside it, which was why it has been described as a little bit fictional. The 2D game was written in Java and C++ native code. It was, however, agreed that this game will be simple and did not take a lot of resources from the computer. Based on these criteria, this game was given lesser attention during the development stage. Most of the main focus on David War Games will be on the 3D game. The 3D game, which forms the main component of the David War Game, was written based on the concept of few commercial games, such as Battlefield 1942, Medal of Honor, just to name a few. It has a powerful 3D engine, the DX engine, to run the 3D game. The DX engine principle and concept was based on the games Quake and Doom, which emerged as the Best Seller in the time of its release. The 3D game was subdivided into a few components, which were 3D objects, Map, Path Finding, AI for enemy unit, Texture Mapping and Lighting, Collision Detection, and Scripting. The UI for the game was made as simple as possible, while providing some cool features and effects to the user. It was, however, agreed that the UI for the game must not consume too much memory, so as not to burden the program when it runs. Some of the UI for the game, such as Buttons, and Panels, will be developed in Java, due to its portability, while some other components are developed in C++ native language, due to the great flexibility provided by that language. During the final stage of the development of the program, the whole program will be converted to machine languages, or C++ equivalent, so that the program will work based on the machines, that is the program will run in Executable (.exe) file. The program will also be equipped with an installer as its development tools. However, the issue of using the Installer has yet to be decided, but few have been proposed, such as the InstallShield, Advanced Installer, and Excelsior JET Evaluation Package.
David War Game Final Report Final Year Project 2004/05 The menus for the program were developed with great care. Many feedbacks from various Game Users have been collected during its development stage. The Game has New, Load, Save, Back, About, Options, and Exit features, which were part of the necessary requirements for a normal game. Extra features, such as Tutorial and Unit Editor, were also taken into consideration in the development stage. Other basic necessities, such as Video, Sounds, and Graphics, were developed for the game. The game used the JM (Java Media) Studio as part of its Video Playing facilities, while various sound players were needed for the game. These include the javazoom packages, and the javax.sound library. The game provides supports for MPG format for its videos capability, while it has WAV, MP3, AIFF, AU, OGG and other supported format for its audio capabilities. The support for MOV and BIK format will be considered during the later stages of the program development. The concept of the 2D game was based on the RPG (Role Playing Game) concept, while the 3D game was based on the First Person Shooter concept. The 3D game has the same components as the commercial game, such as different ammunition and weapons given to the player, 3D scenery, Health Bar, cheats code availability, difficulty choices, music and video support for the game play and storyline. The 2D game was written based on the Super Mario Bros. Concept, but in a substandard implementation. The 3D game will have scripting implemented, if possible, which will give some enhancement for the game play and cool effects for the environment created. Finally, the game will be implemented in a simple but professional way, due to the authors lack of experience and knowledge in the programming field. The scope and skills required for the game development are very high, therefore it is impossible to develop a good game for a short duration of only one year, and by one developer. However, the development of the game was partially guided and advised by some experienced programmers around the world, which were of great help.
1.4
Motivation for the Project
The author of this report has chosen to do War Game for the Final Year Project based on several reasons. First, it was a very challenging task to do a War Game, given that a game need to be developed in a group of about 20 and 2 years time of development period. The author also enjoys playing games as part of his hobby, thus the author has some basic know ledges about the type of games and their game play. Moreover, the author has a lot of skills in the C++ and Java Programming languages, thereby the requirement of implementing the War Game in these languages will not affect the Project. The scope and requirement of the War Game were very large, so this project needs a specialized programmer to handle it. The author of this report was truly amazed by the largeness and complexity of the project, and successful completion of this project will give the programmer a vast amount of experience and knowledge in developing a game.
1.5 Aim
The aim of the project is to develop a War Game that was based on the Commercial Games such as Battlefield 1942 and Medal of Honor. The program will have 2D and 3D features, with a DX 3D Engine used in the implementation for the 3D game core unit. Multimedia aspects such as audio and video were one of the main considerations when developing the project. Furthermore, the game will be equipped with cool and interesting User Interfaces.
1.6
Area/Scope
The area of this project covers the programming, and a moderate reading and analysis on some commercial games. Knowledge of the 2D and 3D games is of much importance, which covers the area of Java, C++, and OpenGL. The ability to use Maya and 3D Max is also an important requirement for this project. The scope of the project covers all the graphics programming, with sound knowledge of Sound and Video Player, such as the Real One Player. It was expected that some commercial games to be obtained and tested before doing this project. The project needs full knowledge of AI, such as A* Heuristic search, Pareto Optimality, Evolution Programming, Genetic Algorithms and some basic searches. Mathematical theories, such as Matrices and Vectors, are needed for developing the 3D game. The principle of transformation was the core of the 3D game programming. A good knowledge in the military aspect, such as weapons, strategy, and tactical command, is required for developing the program used in War Game. In short, the development of the project needs wide knowledge in Game Programming, Multimedia and Military for its development phase.
1.7
Objectives
The objectives for the project are: 1. To develop a 2D game. This includes a hero (player), enemy units (soldier, tanks, space ships, etc.), a 2D environment, some icons (points, health, goals), and secret levels. 2. To develop a 3D game. This includes a hero (player), different weapons (machine gun and rocket launcher), enemy units (Tanks and soldiers), secret units, secret levels, health boxes, a 3D environment, and most importantly, a 3D engine that runs the 3D game. 3. To develop a Video Player that supports MPEG format. This will probably be the JM Studio that was developed by Sun MicroSystem. Consideration will be taken into the RealPlayer that was developed on Java Platform. 4. To develop a Sound Player. This includes the predefined library provided by the Java JDK, such as javax.sound and the freeware product by the javazoom community. 5. To develop a good User Interface. This includes the menus, buttons, animations and background images. 6. To give the user an understanding about the World War 2 story, its history, how it happens and cause of the war. 7. To give the user some knowledge of World War 2 weapons, vehicles, and War Scenery.
1.8
Methodology
The methodology used for the project is RAD (Rapid Application Development). [5 of R1] The general structure of RAD is: Requirement planning Identify objectives and user requirements RAD design workshop Work with user to design system; Build the system Implementation Introduce the new system
The RAD is chosen as the preferred methodology. RAD methodology started with a requirement specification. In this stage, the requirement and analysis of the project will be determined. After the analysis stage has been completed, the general structure and design of the system will be carried out. It is during this stage that user involvement is needed. Then, the system will be coded and programmed. After certain period and time, usually around a month or two, the programmers of the system will meet up with the users and communicate with them. Any problem and issues will be handled during this meeting. This process will be repeated until the users are satisfied with the system. After the system has been completed, it will be released. Then, after a year or two, the system will undergo maintenance and upgrade phase, where the system will be enhanced further and repair when needed. [6 of R1] RAD is chosen for the following reasons: [7 of R1] 1. RAD requires high user involvement, which the project needs in its development stage. 2. RAD also enables a program to be frequently changed and updated. 3. David War Game needs a lot of user feedback and analysis, as these will give improvement for the program, and RAD provides the best in this aspect. 4. The project needs to be completed in only one year, therefore approaches with RAD will help in the development of the project as it will shorten the time used in the development process. 5. The team involved in this project has a good understanding in the project, therefore it is more appropriate to use RAD as the methodology.
David War Game Final Report Final Year Project 2004/05 SDLC (System Development Life Cycle) is known for its lack of User Involvement, so it would not be an appropriate choice as the chosen methodology. Waterfall model is unable to adapt to rapid changes, therefore making it a poor choice for the project. V Model might suit the project, but it lacked the advantages that can be provided by RAD. [8 of R1]
10
1.9
Software/Hardware requirements
The Software and Hardware Requirements for this project would be as follows: Software Requirements are as follows:
1. Java JDK library, particularly JDK 1.4.1, JDK 1.4.2, JDK 1.5.0 2. Sun One Studio 5 Standard Edition. 3. JBuilder X Foundation. 4. NetBeans 4.0. 5. JRun 4.0 6. JCreator 3.0 Professional Edition. 7. Microsoft Visual C++ 6 Professional Edition. 8. Ease MP3 WAV Converter. 9. MP3 WAV Converter. 10. Java Zoom MP3 Decoder. 11. Maya 3D Software. 12. 3D Max. 13. 3D Xara Animator. 14. Easy GIF Animator. 15. 3D Flash Animator 5. 16. Advanced Installer. 17. Install Shield X, Install Shield Admin Studio, Install Shield Dev Studio. 18. Install Anywhere, Zero G Software. 19. Excelsior JET Professional Edition. 20. Real One Player. 21. Moho. 22. Quick Time Player. 23. Java Media Framework 2.1.1. 24. DJ Java Decompiler. 25. MIDI Converter 3.2. 26. Adobe Acrobat 6.0 Professional. 27. Microsoft Word. 28. Microsoft PowerPoint. 29. Microsoft Project. 30. Microsoft Visio Studio. 31. Microsoft Excel. 32. Windows Fax Viewer. 33. Open GL libraries.
11
Hardware Requirements are as follows:

1. An Intel Pentium 4 2.4 GHz or equivalent, with a memory of 512MB and disk storage of 30GB, preferably 1024MB of memory, and 60GB disk storage. Needs a minimum of 64MB graphic card. (eg. 64MB NVIDIA Ge Force 4) 2. A monitor, mouse, keyboard, and speakers. 3. Supports Direct X 8. 4. A CD player of 52X speed or DVD ROM of 16X speed to install the game.
Choice of system requirements:

Programming Languages: Java was chosen because it is Platform and OS (Operating System) independent. It also has efficient memory management which is managed by the Java Garbage Collector. Java is simple to use and well known for its portability. Not only that, Java is more secure as it does not have pointers. C++ was chosen because it supports template. Moreover, it runs ten times faster than a Java equivalent code. C++ runs in Executable file depending only on WinTel platform, while Java Executable file still needs to depend on JDK library. C++ Executable file is unreadable, while Java jar file can be decompile by any freely available software into a Java readable file. OpenGL was used because it has efficient running time. However, it depends on that particular Graphic Card being used. The final version of David War Game will be converted to Exe Executable file to compensate for the above factors. Java Compiler: JCreator 3.0 is known for its simplicity in design and structure. However, it is lack of certain features such as Code Template (Display the method and attributes upon pressing .), ability of creating Executable JAR files, and Efficient Build Coding. It is best known for its fast execution speed, compiling time, and loading time when started. Moreover, its file size is about 1MB-2MB, which will save the hard disk space. JBuilder is known for its widespread use, and popularity in the commercial market. Its product supports most of the Java Program Requirements, with ability to support Net Beans IDE and Networking Features. It also has the ability to create a native executable file from a given JAR file. The loading time for start up is above average, while the support for Code Template is good. It has better text highlighting feature, thus enables clearer representation of code syntax By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 12
David War Game Final Report Final Year Project 2004/05 and structure. It also has ability to draw GUI on the screen while the program will generate the coding at the same time. However, it lacks support for creating a non package Java file, as it is Project Based Applications. Sun One Studio is known for its expertise in Java Programming Language. In fact, Sun Micro System [O1] is the founder and developer of Java Programming Language. It has the ability to draw GUI on the screen. It also has the ability to create Executable JAR files, where most of the compilers are lack of at the moment, and ability to create non package applications. However, it has a slow start up time and inefficient Code Template features. Given the point above, if the programmers are really concern about execution and loading time, JCreator and JBuilder would be the preferable choice. If the programmers are really concern about ease of programming, JBuilder and Sun One Studio would be the choice instead. Anyway, most people would prefer to use JBuilder, followed by Sun One Studio, and JCreator. The author of this report would prefer to use Sun One Studio, while JCreator and JBuilder would be the second choice. Graphical Software: 3D Max is the most widely used graphical software for 3D graphic design. However, it is expensive and costly to the programmer involved. It supports most of the graphical extension, such as .3ds, and .obj. It also has easy to use and user friendly menus for creating a particular 3D graphics. Maya, on the other hand, has limited capability compared to 3D Max. However, it is less costly compare to 3D Max. If the programmers do not mind paying more for the software, the 3D Max should be the choice, else Maya should be the choice instead. Audio Converter: Many Audio Converters are available in the market. Some have more features than others, while some are cheaper than others. The choices for Audio Converter for this project will focus on its Audio Quality, with emphasis on its availability. (Freeware product would be prefer more than those that are not)
13
David War Game Final Report Final Year Project 2004/05 Video Software: Many video players can be found on the web sites, such as Real One player, Quick Time player, and the Java JM (Java Media) Studio. However, only one could be used for the project, the JM Studio by Sun Micro System, due to its simplicity and portability. It is worth noting that although Sun Micro System has agreed to release the Source Code for the JM Studio, it is still copyrighted, and there are some restrictions on distribution because of this issue. Other Video Players are Commercially Available, so it is impossible to use them for this project. So, JM Studio will be used for the project due to its simplicity and availability. Audio Software: Same as the Video Player, many Audio Players are available on the web sites, such as Sound Max, and Win Amp. JLayer Audio Player will be used for the project instead, because it is freeware and written in Java. The Java libraries supported WAV, AIFF and AU format, so there is no need to find Audio Player that supports these formats. Installer: Decision has not been made on the choice of Installer at the moment, but few have been proposed, such as Install Shield, Excelsior JET and Advanced Installer. Install Shield is known for its popularity and widespread use. It has support for many platform and languages, such as WinTel, Solaris, Mac OS, Java, Perl, and C++. However, it is costly to the programmers concerned, so this software can only be used if the programmers has adequate budget for the project. Advanced Installer has support for Java Platform. In fact, it is specially designed for Java Programming Language. It is less costly compared to Install Shield. Excelsior JET installer come bundled with the Native Converter. It supports the Installation of the Executable Specific files. Thus, this can only be used on those file that has Exe extension.
14
1.10 Feasibility study

Some commercial games have been obtained and tested before doing the project. It has been agreed that the David War Game must have the minimum aspect of the available Commercial Games, such as a good User Interface, 3D game, an efficient 3D Engine, good memory management, cool graphics and fast processing and running time. The program will be tested by the users between any interval of time, usually around a month or two. Twelve Game Programming books have been obtained too, so that some basic ideas could be used for the project. Four additional books have been borrowed from the library to obtained more information for the project. Interviews and questionnaire were carried out to obtained feedback from game users, giving some basic idea on how to start the project. A search through the web has been done as well, so that some ideas on the available commercial games could be shared. Furthermore, some studies on Online Gaming have been made, particularly studies made on the Java JNLP files, Java Web Start, and PHP Online Gaming. Possibilities of implementing the game on PERL have been considered as well (although this is not really successful after studies have been made). Some initial work has been carried out by communicating with Game Programmers around the world so that feedback from them will help in doing the project. These were done by getting their e-mail account available on Game Programming Books and contact them via e-mail to obtain the information on the games that they have developed.
15
PART II: Analysis And Design
16
Chapter 2 Problems, Studies, and Requirements For The New System

2.1 Overview
The project was carried out with some basic background reading, particularly from the web sites and game programming books [9, 10, 11, 12, 13, 14, 15, 16]. Information on the web sites, and the Game Magazines about the game development was also obtained. The aspect of online gaming, particularly the TCP layer of the OSI architecture, is of special interest. The networking of some games, such as Age of Empires, has been studied in great details. [CD7] Additional features, such as the Plug-In capabilities of the game, have been considered as part of the implementation of the project. Advanced Graphics feature, was one of the main components of the project, besides some other features such as Video, Audio, and cool User Interface were included. On the software aspect, the program for the project was written to be platform independent, using as low memory as possible, while providing a fast execution speed. Consideration has also been taken into account of the possibilities of implementing the game in OpenGL libraries, thus giving the program a boost in its efficiency. The 3D Engine, which serves as the main component for the 3D game structure, is the most important aspect in terms of programming requirement. This 3D Engine is either a newly developed Engine, created from scratch, or upgraded from the work of some other authors. However, it is important that the 3D engine developed will have its basic requirements, such as 3D rendering, 3D transformation, the Texture and Lighting effect, and some interaction of the objects and its environment. The Video component of the system, was taken from a freeware or public domain, and must be compatible with the game under development. It should support the format of MPEG, and if possible, the format of MOV as well. The Audio component of the system, on the other hand, was handled differently. It seems that the Java library has been able to support the format of WAV, AU, and AIFF, thus eliminates the need to find a free source code from the web sites. Moreover, there are many free of charge source codes available from the web sites that can support the MP3 format as well. However, C++ language does not have predefined libraries that can support the Sound Player. Same as Java, there are plenty of freely available source codes for the Audio Player which can be extracted from the web sites.
17
2.2 Problems
Based on the points mentioned above, the problems that can arise in the project can be summarized as follows: 1. The memory requirements. It seems that Java JDK libraries have allocated limited amount of Memory to the System. JDK 1.4.1 allocated a space of about 8MB, while JDK 1.4.2 allocated a space of about 10MB. JDK 1.5.0, known as Tigers, seems to improve a lot compared to the other two, allocating an amount of 20MB, but still it is not large enough for the system being developed. However, the whole Java code can be converted into machine code, thus the program will be dependent on the Machine Memory instead, not the JDK anymore. C++, on the other hand, seems to have plenty of memory allocation for the program. However, it is harder and time consuming to code the entire program. Furthermore, the programmer should be careful in choosing when and where to allocate a memory to the system. This was done by calling the constructor and destructor of the class. 2. Copyright issues. This seems easy to handle, but since the program is big in size, it needs to have a lot of resources for it to be really attractive to the users. It seems that there are a lot of public domain resources on the web sites, but to find a relevant one for the project is a tedious task. Moreover, the file must be attractive enough for the system so that users will find the program interesting when they use it. These resources include Background Images, Music, Video, and some Images for the Object such as Tank. This project was developed solely for academic purposes, thereby reducing the risk of copyright issues as it is protected under the Academic Law and License. [C1] However, the project was expected to have some distribution problem, as some of its sources are from the web sites, and these might be under the CGPL (General Public License) terms, which restrict the distribution process of the system. In other words, the copyright issues will be handled with care and made as minimal as possible.
18
David War Game Final Report Final Year Project 2004/05 3. Choice of languages for the system. Many programming languages have been considered for the project, ranging from PHP, Java, C to C++. However, based on the system requirements, only two have been considered, that is, Java and C++. When choosing a particular programming language, the language capability of Networking, Speed of Execution, the representation of Classes such as Template, efficiency of Memory Handling, and Graphics and Multimedia support for the system had been taken into account. Each language, when reviewed, has its advantages and disadvantages when compared to others. For example, Java has Efficient Memory Handling while C++ has Efficient Speed of Execution. Finally, after careful examinations, Java and C++ have been adopted as the main languages for the system. However, this seems to pose a portability problem on the system, but Java provides the JNI (Java Native Interface) in its library, so the issues of portability will not affect the system. 4. Time for successful completion of the project. This project is aimed to develop a War Game, which has the 2D and 3D game implemented in it. In the real life environment, this project was supposed to be developed in a group, with each of the group member having a good knowledge on his part. Furthermore, the project was expected to be completed in 2 years, provided that the team members are working on a full time basis with full cooperation with each other. However, this project was done by a single Final Year Computer Science student, with quite a good knowledge of the project given. The time for the completion of the project is only a year, compared to 2 years in the real life environment. Thus, the project has been started as early as in the Year 2 of the course, with some helps obtained from the experienced programmers around the world. 5. Software needed for the project. The system for the project needs a lot of additional supporting software to develop it. This software, for a number of 35-40, is very costly for the programmer involved in the project. Software such as 3D Maxs, Borland JBuilder X Enterprise Edition and Microsoft Visual C++ 6 Professional Edition, cost around USD 2500-4000 for each copy. However, with a budget of about USD 5000, most of the software needed such as 3D Maxs can be obtained. 3D Graphical Software, such as Maya can be used instead of 3D Maxs for the development of 3D Models since it is much cheaper compared to the latter. Some software, such as GIF Animator, was used on the Trial basis, and it is used only occasionally.
19
David War Game Final Report Final Year Project 2004/05 6. Other problems. Some other problems, although not very important, had been encountered in the project. This includes the problem of demonstrating the project in the Computer Laboratory, where the resources were limited and in small quantity. The Computers in the Laboratory have Installation Restrictions, thereby restricting the demo task during the open day. Other problems include Report Writing, where the amount of words in the report has to be restricted although the project size and scope is very big.
20
2.3 Studies on some games of the current system

Several games, such as Medal of Honor [CD1 of R4], Battlefield 1942 [CD2 of R4], have been obtained in order to determine the requirement of the proposed system. Features in the commercial games, such as its video, audio, Graphics, and Menus have been studied and tested carefully. The games being tested were based on the concept of First Person Shooter. The commercial games are based on the War Story, particularly the World War 2 story. Most of the games have their own Video Player, thus it is necessary to have Video Player as part of the requirement of the project (See figure 2.2.1). Audio Player is also part of most of the games, with most of them support MP3 and WAV format only. All the games have two type of sound player, one that plays the Background Music, and the other plays the Object Interaction sounds. A good menu, with attractive Buttons, and Radio Buttons is normally a feature of the game. Moreover, a Cool and Attractive User Interface (see figure 2.2.2), a background images, with some buttons on top of it are also features of a good game. Most of the games also have Video Playing during its introduction, showing the initial storyline of the game. Some Games, but not all, have implementation of Online Gaming as part of its features (see figure 2.2.3). However, very few games have Plug-In capabilities on it. In fact, only one game tested in this project has Plug-In capability implemented on it. Most of the games were designed to work on WinTel platform, but not on the UNIX or LINUX platform. All the games have a good about menus, showing the names of the people involved in the project, with few of them showing the story of World War 2 in its about menu (See figure 2.2.4). All the games have Options menu, where the user can configure the mouse and keyboard mapping, as well as adjusting the sound and graphics level. (see figure 2.2.5) Only Strategy [CD3 of R4, CD4 of R4, CD6 of R4] based games have Unit Editor implemented in it, whereas none of the First Person Shooter games has Unit Editor in it. All the games studied by the author have its own 3D Engine, with some being better than others, and the games have Save and Load features in them, and they follow the same rules and concepts for these features. Most of the First Person Shooter [CD5 of R4] games display a weapon in front of the player during game play. These games also display a list of weapons for the player to choose. The weapon shows some special functions when used. (See figure 2.2.6 and 2.2.7) All the games have features that are cool and attractive to the users, in order to make it attractive to the user. Most of the games have been programmed based on the real life environment. By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 21
Figure 2.2.1 A scene displaying the introduction movie in Caesar III Image courtesy of Sierra
Figure 2.2.2 An intro menu in Caesar III Image courtesy of Sierra
22
Figure 2.2.3 An Online Gaming features in Battlefield 1942 Image courtesy of Electronic Arts
Figure 2.2.4 An about menu in Battlefield 1942 Image courtesy of Electronic Arts
23
Figure 2.2.5 An option menu to configure the key mapping Image courtesy of Electronic Arts
Figure 2.2.6 A First Person Shooter Scene from Rainbow Six Rogue Spear Image Courtesy of Red Storm Entertainment
24
Figure 2.2.7 A scene from Battlefield 1942 Image courtesy of Electronic Arts
25
2.4
Related Works
Commercial Games and its weaknesses The studies made on commercial games will emphasis more on the First Person Shooter Concept. As have been mentioned in the previous section, most commercial games have the same features, mainly a good UI Menu, followed by good storyline and game play. Some games will have extra features such as Plug Ins. The features available on the commercial games are as follows: The important features: 1. Good UI Menus. 2. Interesting storyline. 3. Good game play. 4. Good graphics. 5. An efficient 3D Engine. 6. An about menu. 7. Easy to use Setting Features. 8. Save and Load Features. 9. Good Audio Capability. 10. Beautiful Background Images. 11. Realistic Weapons and Vehicles. 12. Realistic 3D Environment and Scenery. 13. Good Library Menu. 14. Online Gaming. Optional Features: 1. Plug In Features. During the testing phase on the available commercial games, the weaknesses detected in the game will be noted. These weaknesses will be taken as part of improvement for the David War Game. The weaknesses in the Commercial Games are as follows: 1. 2. 3. 4. Some games have some serious bugs, such as Unwanted Termination of Game. Some games need high requirements in order to run. Some games have irrelevant videos and audios. Some games are lack of story line.
26
David War Game Final Report Final Year Project 2004/05 No doubt that every game has its own weaknesses and strength, the most popular commercial games such as Medal of Honor has very little weaknesses compared to other. Based on the studies made, it has been agreed that David War Games will have the following: The important features: 1. Good UI Menus. 2. Interesting storyline. 3. Good game play. 4. Good graphics. 5. An efficient 3D Engine. 6. An about menu. 7. Easy to use Setting Features. 8. Save and Load Features. 9. Good Audio Capability. 10. Beautiful Background Images. 11. Realistic Weapons and Vehicles. 12. Realistic 3D Environment and Scenery. 13. Good Library Menu. 14. Online Gaming. 15. Map Editor. Optional Features: 1. Plug In Features. Features that is not available in the commercial games: 1. Unit Editor. 2. Meta Programming. As can be seen from above, David War Games will have Unit Editor and Meta Programming as part of its features. The description of these new features is as follows: Unit Editor The ability to create your own enemy unit that satisfies your own criteria. Meta Programming The creation of a highly complex 3D Environment, while providing some help on the players action and interaction with other objects in the environment. By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 27
David War Game Final Report Final Year Project 2004/05 David War Game will also solve the entire problems that have been encountered in the commercial games. This could be done as follows: 1. The system would be made as stable as possible. This is needed to ensure that the system would not crash in the event of a failure, such as unwanted termination of the program. 2. The system would need simple requirements in order to run. Currently, the system needs Java JDK in order to run, with a moderate processor and memory requirement. However, this system does not needs requirement as high as those widely available commercial games, such as Doom 3. 3. The system will have relevant story line. Most of the commercial games do not seem to have this problem, so this issue will be taken lightly.
28
2.5
Requirements of the new system
Based on the point given in Section 2.1, a few general guidelines have been proposed for the requirements of the system to be developed. It is worth noting that the system will be developed like those commercial games, to be as good as possible, even though the project has some limitations in it, such as financial resources. The requirement for the system would be as follows: 1. The system would have the basic necessities, typically a good User Interface and its related component such as Buttons, and Radio Buttons. The Buttons for the system need to be implemented from scratch as the Button class provided by the Java JDK library was not good enough. The system would be equipped with a Video Player. This Video Player will support the format of MPEG, and if possible other formats as well. The Video Player will have all the features of a Video Player, such as Loop Playing, Stop, Resume, Open, New, and so on. The video player should also support the video files that are available on the Internet, typically accessed through the URL. The system should have some audio capabilities, which support WAV, and MP3 format. The Sound Player provided by Java Libraries have support for AU and AIFF format, which gives the system more choices and flexibility in running the audio file. However, the system does not really need a User Interface for the Sound Player. The system needs a 3D Engine, which serves as the main component for the 3D game. The Engine should have support for all the basic necessities of the game, such as 3D rendering, Object Interaction, Lightings, Collision Detection, and Animation of Objects. The 3D Engine would be named as DX Engine, which stands for David X Engine. The system should have support for Online Gaming, which runs through the TCP and IP protocol. It should provide the interface for user to play with other user around the web by selecting some options on the user friendly menus. In Java, these can be done in the package of Java NIO libraries. However, this has some limitation for implementing the online feature fully. It is not clear at the moment whether the Online Gaming features will be implemented in Java or C++. The system should provide some Plug In capabilities. This would let the user to create a map or an object that is understood by the system. Then, the user would run the game and load this map or object. The game would load and run the required map or object that is selected by the user. The system should have a Unit Editor implemented in it. This means that the system will give the user a list of choices for the user to create an enemy unit. After creation of that enemy unit, the code will be saved in a file with extension OBJ. Then, when the game starts, the system will load the newly created enemy into the map. 29
2.
3.
4.
5.
6.
7.
2.6
Task Management
The scope and area of the project are really huge. Therefore, the War Game Project needs to be divided into few subsections and areas. It was agreed that the War Game Project will be divided according to the real life Game Project development phase. The Project uses the RAD (Rapid Application Development) methodology, so users involvement must also be taken into account for the development of the War Game. In any available commercial games such as Medal of Honor, the development of the Game Project can be divided as follows: 1. The User Interface Design This part would include the design of Interactive Buttons, CheckBoxes, Scroller, Menus, Panels, and other related component. The components must be attractive enough to the users so that the users can enjoy the gameplay. The component must be created from scratch, from the level of graphics, border, listeners and text manipulation. The author of this report would do this part alone, with reference to some of the commercial games. 2. The 3D Engine Design Most commercial games have a good 3D Engine, with capabilities to handle 3D environment and objects, while providing the effects as well. A better 3D Engine can be judge from its graphics output, in the aspect of realism and interactivity. In David War Game, the 3D Engine implemented would be as simple as possible, due to the lack of experience in Game Programming, with some supervision from the Game Programmers as well as some Game Books being bought. 3. The AI for the game A good game would have a good and advanced AI implemented in it. A typical example of a commercial game with a good AI implemented would be the Commandos 3, Destination Berlin. The enemy in this game can hear, see and shouted for help. A soldier can look at different angle for the enemy, while being in different state, such as Alert, Defense, and Attack. Whenever he senses some dangers, he would automatically shouts for help, and raises the alarm, if possible. The author would implement the AI for the War Game, with some help from the Game Programmers, if possible. 4. The Audio Player Most commercial games have audio player that supports WAV and MP3 format. However, some games support MIDI format as well. The David War Game will have support for MIDI, WAV and MP3. Some Audio Players, particularly the MP3 Player, would be taken from the Public Domain sources, particularly the javazoom package.
30
5. The Video Player Some commercial games support MPEG format for its video capability, while some support BIK format for its Video Player. David War Game will have the Sure Player for its Video Player, which supports MPEG format. David War Game might have the JMF (Java Media Framework) Video Player as well. (Developed by the Sun Microsystem). 6. The Graphics Design This includes the Texture Mapping, Lightings and others. The Graphic Design would be fully implemented by the author of this report. 7. The Implementation of Scripting This feature would be giving some enhanced playback for the users. Some typical examples include a moving gate, a collections of stone to cross the river, and secret stair to go to a secret level. The purpose of Game Scripting is to make the System more efficient, while providing more fun during the gameplay. However, this feature will be taken lightly due to the lack of time given in the project. 8. The Open GL functionalities David War Game will made use of the GL Libraries for its graphics capability. However, this feature as well, will be taken lightly due to the lack of knowledge in OpenGL programming. The figure below shows the Task Management for David War Game. (Based on the commercial game Medal of Honor)
Figure 2.7: The Task Management for David War Game
31
2.7
Literature Review
An overview of the history of gaming industry: The birth of the gaming industry In ancient times, the games developed were mainly based on the simple concept. Some of the initial games were Royal Game of Ur, which was created during the Babylonian time, dated back 2000 BC, Wei Qi, which was created by Chinese, and Backgammon, which dated back 1 AD. After the birth of computers, computer games were not really popular. It is during the 1966 where the game started to develop. In 1966, the US government started a project to develop a game for its military project, in order to deal with the surge of the communist might. The project, which has the nickname SpaceWar, was founded by the company Sanders Associate. The team was lead by Ralph Baer, with a group of about 500 engineers. The team has successfully developed a hockey game. This game has a ball which is turning and rotating around in a space. No doubt that the job done by Baer did not really seems to attract the attention of US military staff, but it has marked a new beginning of an important field, Game. First Generation System, 1972-1977 During this period, the gaming industry started to develop further. Nolan Bushnell and Al Alcorn, who founded Atari, one of the leading gaming industries during its time, have managed to create a game known as Pong. It had a built in paddles, a built in speaker, and a preprogrammed Pong. However, the gaming industry is still at its infant stage, with only a few game companies emerged, one of them is Atari.
Figure: The Pong Machine
32
David War Game Final Report Final Year Project 2004/05 Second Generation Systems, 1977-1981 Unlike before, the game programming started to become more complicated. It is during this period that game programmers started to work in a group. Furthermore, the graphics and audios features of a game become more complicated and advanced. A good example would be the Atari's VCS/2600 game machine.
Figure: ATARI 2600 Third Generation Systems, 1981-1984 It was during this period that game industry suffered the most. The profit during middle of this period was only $100 million, compared to $3 billion during last period. The reason behind this dark ages was mainly due to the technology changes in the market. The magnetic tape has been invented and was soon to replace the ROM cartridges. Moreover, the good values of magnetic tape seem to outweigh those of ROM cartridges, in terms of speed, access time, and storage capacity. Atari, on the other hand, has a different point of view. It claims that the magnetic tape is too fragile for the consumer to handle. This has lead to the customer trends to change from playing a home game machine to the arcade style game machine. This strategy has lead to Atari to lose in the future battle with other emerging game companies, such as Nintendo. Fourth Generation Systems, 1985 -1989 Few interesting thing happens during this period. First of all, it is during this period that Atari has begun to fall apart. This has lead to the emergence of new game companies, such as Sega, and Nintendo. Furthermore, the technology changes drastically during this period. DRAM (Dynamic Random Access Memory) was invented to replace the existing ROM (Read Only Memory). Fifth Generation Systems, 1989-1995 Emerging game companies, such as Nintendo and Sega, started to boom in its businesses. It was also during this time that the processor was invented. Many new machine were introduced into the gaming market, such the as Genesis, which uses 16 bit technology. Sega introduces its TurboGraphix, in response to the emergence of Genesis. The battle between two emerging game companies, Sega and Nintendo, started to erupt. However, there was no winner and loser in this battle as both companies product are attractive and economical to the users.
33
Sixth Generation System, 1995-Present More new game companies started to join the battle, such as Microsoft Inc. Microsoft introduces its new game machine, the X Box, which was intended to dominate the gaming market. On the other hand, Sony introduces its game machine, Sony PlayStation, which was soon replaced by a more powerful machine, the Sony PlayStation 2.
Figure: Sony PlayStation 1 A Glance At A Game Company, ATARI Inc.
Figure: ATARI Inc. Logo ATARI was founded in 1972. It was one of the oldest game companies in the world. ATARI introduced the working concept of coin-op games. With the release of its first few games, such as Pong, ATARI makes a profit of $28 million in 1976. In 1977, it introduces a video game machine, ATARI 2600. In 2000, Hasbro Inc. (The founder of the Transformer) was sold to Infogrames, a holding of ATARI Inc. No doubt that ATARI has lost its popularity compare to its early period, it was interesting that ATARI remains a name of recognition and familiarity for more than 34 years. Source of Information: http://www.geekcomix.com/vgh/ggg2.shtml (Game industries) http://www.tformers.com/article.php?sid=2817&mode=flat (ATARI Inc.)
34
2.8 Pseudo code

Below are the pseudo code planned for the project (Subject to change): GameCore (Main Menu): //initialize program While(true){ //run the program //refresh the screen //update the system //draw specific component } //exit the program Description: When the system started, the system would initialize itself by setting up the necessary variables (e.g. User Interfaces codes). Then the program will go into a while loop. The program will only go out from the while loop when the user presses the ESC key. It is inside this while loop where all the functions and works are done. In the Game Core, the system would repaint the screen every 10 milliseconds, thus gives the user a constant and continuous feel of screen display. If there are some actions being performed in the system, it is in the update method where the system will handle these tasks and the result of these tasks will be displayed in the subsequent draw method. The system would continually repeat this process until it exits. It is worth noting that the graphics for the system would be dispose and redraw every 10 milliseconds.
35
David War Game Final Report Final Year Project 2004/05 2D Game: //load map //load object while(true){ //run the program //refresh the screen //update the system //draw specific component } //exit to main menu Description: The 2D game system shares the same algorithm with the Game Core. However, the update and draw method will perform different task when called. In the Game Core, the update method will update the actions of key and mouse event only, while in the 2D game, the update method will update the environment, enemy units, and objects, besides updating the key and mouse actions. The draw method will draw the environment and objects with respect to the current conditions, while in Game Core this method will draw the Background Images and Frames only.
36
David War Game Final Report Final Year Project 2004/05 3D Game: //load map //load object //load loader menu while(true){ //run the program //refresh the screen //update the system //draw specific component //handle event //handle actions } //exit to main menu Description: The 3D Game algorithm has nearly the same structure as 2D Game except that it is more complicated and bigger in size. The update method of this algorithm will update the environment, objects as well as the Artificial Intelligence Components of the system. The draw method will draw the necessary objects and its environment, like in the 2D Game, except that the screen will display 3D environment instead of 2D. After this process, the system will handle all the events and actions, such as Jump, Walk, and Shoot. This also includes the enemy events and actions.
37
David War Game Final Report Final Year Project 2004/05 Tutorial: //load map //load object //load loader menu while(true){ //allow only basic features //run the program //refresh the screen //update the system //draw specific component //handle event //handle actions } //exit to main menu Description: The Tutorial Algorithm has the same structure as the 3D game, except that it is capable to handle the sequence of players actions. This is needed so that the system will know what the player is doing and gives some guidance to him about the next steps to follow. Some features have been disabled from this algorithm, by setting the Boolean condition. Library Menu: //load library menu //display menu if(BACK) //go back to main menu Description: This algorithm has a simple structure and design, and is associated with the main menu.
38
David War Game Final Report Final Year Project 2004/05 About Menu: //load program //display //load thread //play animation //exit on pressing OK button Description: This algorithm also has simple structure and design. It consists of a thread, which will play the text and music, as well as capability to display some images. Unit Editor: //load program //display menu //display graphics while(true){ //run the program //refresh the screen //update the system //draw specific component } //exit on pressing ESC Description: The Unit Editor inherits the capability of the 3D Game. However, some changes have been made to the parser, and object loader, such that the system could construct the unit by part, not on the whole. (The system could construct individual head and body, but not the whole tank). An easy and user friendly menu has been provided to the user to enable the task of constructing an enemy unit.
39
David War Game Final Report Final Year Project 2004/05 Save: //action handler if(OK or CANCEL) //to main menu else //save to file Description: The Save feature has simple and easy to use design. However, it has some restriction in the system thread that results in it to be implemented in a substandard manner. The Java Serializations API is not powerful enough for the system, thus this factor as well limits the Save feature to be fully operational. Load: //action handler if(OK or CANCEL) //to main menu else //load from file //play the game Description: The Load feature has the same structure and design as the Save feature, except that it has some screen shots of the previous game saved.
40
2.9 The Design Structure of David War Game
Figure 2.6 The Design Structure of David War Game Description: Figure 2.6 shows the designs of David War Game. All the classes inherit from one main class, the GameCore class. It is in this class that the memory handling is handled. It is also in this class that the screen are refresh and redrawn. The GameCore class has an abstract method update, which will be overridden in the sub class. For the main menu, the class will have UI, which will inherit InputManager and GameCore. InputManager class serves to handle the key, mouse and event handling. For 2D Game, it will have 2DGame class that will inherit GameCore. This class will load the map, create objects and handle collision detection. This class also overrides the update and draw method of the parent class. For 3D Game, the game structure will have AIAndEvolution class, which inherits ShooterCore, 3DGameCore, and GameCore. 3DGameCore will overrides and enhance the features provided by GameCore. On the other hand, Shooter Core class will handle the player and its related task, such as Event, Key, and Mouse Handling, while handling the camera and view features as well. AIAndEvolution class is merely about the enemy unit and its environment, where the system will determine the behavior and characteristic of enemy units, and determine their next actions.
41
Object Representation
David War Game involves creating enemy unit. This enemy unit must have some specific algorithm and structure in order to create it in the 3D Environment. Below is the format of the enemy unit OBJ file: # OBJ - Wavefront object file # The javagamebook loader only understands these commands: # mtllib <filename> - Load materials from an external .mtl # file. # v <x> <y> <z> - Define a vertex with floating-point # coords (x,y,z). # f <v1> <v2> <v3> ... - Define a new face. a face is a flat, # convex polygon with vertices in # counter-clockwise order. Positive # numbers indicate the index of the # vertex that is defined in the file. # Negative numbers indicate the vertex # defined relative to last vertex read. # For example, 1 indicates the first # vertex in the file, -1 means the last # vertex read, and -2 is the vertex # before that. # g <name> - Define a new group by name. The faces # following are added to this group. # usemtl <name> - Use the named material (loaded from a # .mtl file) for the faces in this group. A more detail explanation of the OBJ file format will be given in the implementation part of the report. Basically, an object consist of PolygonGroup, which is formed by a set of 3D vertices (x, y, z). An image file defined in the texture mtl file will be mapped to this polygongroup, thereby forming a rectangular cube. Multiple polygongroup will form an enemy unit.
42
MAP File
David War Game also involves creating a 3D Environment. This is done by creating a readable, MAP file. The format of the MAP file is as follows: # MAP - backart2 map format. # # v [x] [y] [z] - Define a vertex with floating-point # coords (x,y,z). # mtllib [filename] - Load materials from an external .mtl # file. # usemtl [name] - Use the named material (loaded from a # .mtl file) for the next floor, ceiling, # or wall. # ambientLightIntensity # [value] - Defines the ambient light intensity # for the next room, from 0 to 1. # pointlight [v] - Defines a point light located at the # [intensity] specfied vector. Optionally, light # [falloff] intesity and falloff distance can # be specified. # player [v] [angle] - Specifies the starting location of the # player and optionally a starting # angle, in radians, around the y-axis. # obj [uniqueName] - Defines an object from an external # [filename] [v] OBJ file. The unique name allows this # [angle] object to be uniquely identfied, but # can be "null" if no unique name is # needed. The filename is an external # OBJ file. Optionally, the starting # angle, in radians, around the y-axis # can be specified. # room [name] - Defines a new room, optionally giving # the room a name. A room consists of # vertical walls, a horizontal floor # and a horizontal ceiling. Concave rooms # are currently not supported, but can be # simulated by adjacent convex rooms. # floor [height] - Defines the height of the floor of # the current room, using the current # material. The current material can # be null, in which case no floor # polygon is created. The floor can be # above the ceiling, in which case a # "pillar" or "block" structure is By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 43
David War Game Final Report Final Year Project 2004/05 # # # # # # # # # # # # # # # # # ceil [height] created, rather than a "room". - Defines the height of the ceiling of the current room, using the current material. The current material can be null, in which case no ceiling polygon is created. The ceiling can be below the floor, in which case a "pillar" or "block" structure is created, rather than a "room". wall [x] [z] - Defines a wall vertex in a room using [bottom] [top] the specified x and z coordinates. Walls should be defined in clockwise order. If "bottom" and "top" is not defined, the floor and ceiling height are used. If the current material is null, or bottom is equal to top, no wall polygon is created.
The map file has objects, walls, ceilings, and floors specified in it. It can also have lighting to be called from this file. However, a single mistake of typing in the file will results in an incomplete map being formed. For more details about the map, please refer to the implementation part of this report.
44
Chapter 3 Requirement Analysis For The Proposed System

3.1 Core unit and structure of the program
Generally, the system was designed to have low memory usage, a fast execution speed, and cool components.
3.1.1 Memory
Java allocates a memory space of around 8MB to 25MB, depending on the version of the JDK. C++, on the other hand, allocates memory based on the Computer Specification. Java memory handling is very efficient, with the capabilities of Garbage Collection, which automatically dislocate a memory space when no reference is referred to the object anymore. C++ uses manual memory management, but if the programmer knows how to handle memory efficiently, the memory handling in C++ will be even better than in Java. This requires some tricks when the programmer wants to allocate and dislocate the memory from the object. No doubt Java provides limited amount of memory for the system, this problem can be easily solved by converting the whole Java codes into machine codes. Alternatively, the whole Java codes can be rewritten into C++ equivalent codes. This task would require substantial amount of hard work, so it is advisable not to carry out these steps. In general, the system requires a memory space of about 256MB, preferably 512MB for more efficient running time. The system needs at least 500MB of hard disk space, but a hard disk space of about 700MB would be preferable for the system. The system also needs a 32MB Graphic Card, and a support for Direct X 8, and Open GL functionalities. It is worth noting that some part of the system has been coded in Open GL (Open Graphics Library).
3.1.2 Speed
The system needs a fast running speed, so a powerful Computer is needed for the system. In general, the system needs a CPU speed of 2.4GHz, with 1MB L2 cache. C++ code runs about ten times faster than Java code, but this is not a problem as Java code can be converted into machine code, which runs very fast eventually.
45
3.1.3 Components
The system should have the basic components, namely the Panels, Menus, Buttons, Lists, RadioButtons, and some basic images. Background images will be needed for the system so as to enhance the realism effect of the system. The system would be divided into 2 main parts, the 2D and 3D. 3D would be larger than the 2D, in terms of complexity and size. Most of the system structure and components would be in the 3D.
46
3.2 UML As A Modeling Tool For The Proposed System

Unified Modeling Language
According to Oestereich [1 of R1], UML is a language and notation for specification, construction, visualization, and documentation of models of software systems. The current system of UML is 1.4, and it can be seen as industry standard.
Use Case Diagram

Oestereich [2 of R1] States that a Use Case Diagram is a diagram which shows the relationships between actors and use cases.
3.2.1 Use case diagram
Figure 3.1 Use Case Diagram for David War Game Figure 3.2.1.1 shows the Use Case diagram for the system. User interact with the system by accessing the Main Menu, which provides Music, and Cool User Interface, while giving the user a scenario editor and game play.
47
State Diagram
According to Oestereich [3 of R1], a state diagram is a diagram which shows a sequence of states an object can assume during its lifetime, together with the stimuli that cause changes of state. A state diagram describes a hypothetical machine (finite automaton) which at any given time is found in a set of finite states.
3.2.2 State diagram
Figure 3.2The State Diagram for David War Game Figure 3.2.2.1 shows the state diagram for the system. When the user starts the system, it will enter running states. When the program runs, it will have several options available, such as New, Options, Credits, and Library. The user can exits the system at any given time. After exiting, the system will reach its end state. (Based on version v 11.1.1024)
48
3.2.3 Management diagram
Figure 3.3 Management of the David War Game resources The above figure shows the resources management of the David War Game. The system has a main/ core structures, which controls the screen, memory, sound, and graphics. The new version has a management for speed and video as well. (Based on version v 11.1.987)
49
Class Diagram
Oestereich [4 of R1] Says that Class Diagram can be define as the definition of the attributes, operations and the semantics of a set of objects. All objects in a class correspond to that definition.
3.2.4 Class diagrams 3.2.4.1 2D

3.2.4.1.1 2DGame
Figure 3.4 The 2D Game Design and structure The above diagram shows the structure of 2D game. A 2D Game consists of Save and Load Features, Back, A loader of the game, and New Game. (Based on current version, v 1.2.135)
50
David War Game Final Report Final Year Project 2004/05 3.2.4.1.2 2DLogic
Figure 3.5 2D game logic design The figure 3.2.4.1.2 shows the internal logic for the 2D game. It consists of Sound Player, Resource Manager, and a Map Loader. The Main Manager is located under 2D Game.
51
3.2.4.2 3D
3.2.4.2.1 3DAI
Figure 3.6 The AI unit for 3D game. The above figures show the AI structure and unit for the 3D game. The 3D Game has three patterns that are dodging, scared and aggressive. Each of these patterns has its own advantages and drawbacks as well. The 3D game is also equipped with Natural Evolution Techniques, which covers the area of Crossover, Mutation, and Genetic Algorithms. (Data based on version v 1.1.1340)
52
David War Game Final Report Final Year Project 2004/05 3.2.4.2.2 3DGame
Figure 3.7 The 3D game structures The above figure shows the structure of a 3D game. It has a nearly similar structure to a 2D game, except that it is more complicated in design. The latest version is equipped with video and some scripting facilities. (Based on version v 1.1.897)
53
David War Game Final Report Final Year Project 2004/05 3.2.4.2.3 3DLogic
Figure 3.8 The logic behind a 3D game The figure 3.2.4.2.3 shows the internal logic for the 3D game. It has AI as its main component, an object loader for loading objects into the map (such as a tank), a map loader which loads a 3D environment, and path which has A* Heuristic as its core structure. A* Heuristic algorithm 1. Determine the search space 2. Determine the set of every pair of nodes (in the hierarchy). This will be the g function. The nodes will be the portal of the 3D Environment. 3. Determine the heuristic function. This is f function. The smallest value of f will be chosen as the next path.
54
3.2.4.2.4 3DPath
Figure 3.9 The Path Structure for 3D Game The above figure shows the Path for an enemy unit in the 3D game. It has 3 choices, with A* Heuristic being the best choice out of the three.
55
David War Game Final Report Final Year Project 2004/05 3.2.4.2.5 Math
Figure 3.10 The math class for 3D game The above figure shows the math fundamentals needed for a 3D Game. Most of the Math Application will be dealing with Object and Environments interaction.
56
3.2.4.3 Audio
3.2.4.3.1 Audio
Figure 3.11 The Audio for the David War Game The figure 3.2.4.3.1 shows the Audio Unit for David War Games. The implementation is based on javazoom library. It is a little bit too brief in description. It consists of Encoder, Decoder (needed by MP3 file), a Player and an advanced Player as well. (Based on the current version, v 1.2.896)
57
3.2.4.4 Main
3.2.4.4.1 Credit Menu
Figure 3.12 The credit menu in the Main Menu of David War Game The above figure shows the design of credit menu for David War Games.
58
3.2.4.4.2 Library Menu
Figure 3.13 Library Menu for David War Game The above figure shows the Library Menu for David War Game. Unlike other menu, this menu has a loader. 3.2.4.4.3 Option Menu
Figure 3.14 The option menu By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 59
David War Game Final Report Final Year Project 2004/05 The above figure shows the structure for the Settings Menu in David War Game. 3.2.4.4.4 War Game Class Main
Figure 3.15 The main menu design and structure The above figure shows the design for the main menu. The main menu has Option, New, Library, Credit, and Exit. Note that the latest version has Unit Editor and an enhanced structure. (Based on the initial version, v 1.0.0)
60
3.2.4.5 Map
3.2.4.5.1 Map Editor
Figure 3.16 The Map Editor structure The above figure shows the structure of a Map Editor in the 3D game. The principle behind a map lies in the BSP (Binary Space Partition) tree which separates the Plane into several dimensions. It uses Z Buffer to measures the distance between player and other objects.
61
3.2.4.6 Unit
3.2.4.6.1 Unit
Figure 3.17 The Unit Structure (Enemy Unit) The figure 3.2.4.6.1 shows the hierarchy structure for the Enemy Unit. Every Object in David War Game will have Game Object as its parent class. Enemy Unit will have class up to Specific Name. A Health Box will has class up to Game Object while a projectile will have a class up to Path.
62
3.2.4.7 Video
3.2.4.7.1 Video
Figure 3.18 The Video class structure The above diagram shows the structure of the Video in David War Game. It looks a little bit too brief in general. The Video Player supported MPEG format only, but it supports quite a wide range of sound format such as WAV, and MP3. (Based on the initial version, v1.0.0)
63
Context Diagram
Context diagram has the same representation as the package. It describes the components and subcomponents of the system being developed.
3.2.5 Context diagrams 3.2.5 Context Diagram 3.2.5.1 Audio

3.2.5.1.1 javazoomContext
Figure 3.19 javazoom sound player
64
3.2.5.2 Extra
3.2.5.2.1 sunContext
Figure 3.20 sun packages, mainly for the video library packages
65
3.2.5.3 Main
3.2.5.3.1 binContext
Figure 3.21 The bin context, providing some functions for JMF 3.2.5.3.2 bshContext
Figure 3.22 The bsh packages, library class for the Bean Shell Script 3.2.5.3.3 codecContext
Figure 3.23 The codec packages, for coding and decoding of MP3 file 3.2.5.3.4 comContext By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 66
Figure 3.24 Com packages for David War Game The figure above shows the com packages. These packages serves as the main structure and component for the system developed. Most of the system code would be in the Main Core packages.
67
David War Game Final Report Final Year Project 2004/05 3.2.5.3.5 mainCoreContext
Figure 3.25 The Main Core packages Figure 3.2.5.3.5 shows the Main Core packages for David War Game. It is these packages where all the 2D and 3D game code residing in. Part of the User Interface code also resides in these packages.
68
David War Game Final Report Final Year Project 2004/05 3.2.5.3.6 MainProgramContext
Figure 3.26 The MainProgram Packages, including resources and component. The IO and Key Component also resides here. 3.2.5.3.7 microstarContext
Figure 3.27 The microstar packages, gives the game an enhanced UI.
69
David War Game Final Report Final Year Project 2004/05 3.2.5.3.8 nativeContext
Figure 3.28 The Native libraries The above figure shows the native packages. Its in these packages where the C++ code resides and implemented. 3.2.5.3.9 UserContext
Figure 3.29 The starting point for the user
70
3.2.5.4 Map
3.2.5.4.1 mapContext
Figure 3.30 The maps package, storing map for the 2D and 3D game
3.2.5.5 Menu
3.2.5.5.1 LibMenuContext
Figure 3.31 Library Menu package, store the library pictures and files. It contains Java file as well.
71
David War Game Final Report Final Year Project 2004/05 3.2.5.5.2 orgContext
Figure 3.32 the org packages, storing the additional file and settings as well
3.2.5.6 Pic
3.2.5.6.1 fontsContext
Figure 3.33 the fonts packages, for the loader menu
72
3.2.5.6.2 GamePicContext
Figure 3.34 Game Pic packages, storing the menu, backgrounds and buttons picture. 3.2.5.6.3 imagesContext
Figure 3.35 images packages, storing some additional picture files. 3.2.5.6.4 LibPicContext
Figure 3.36 Lib Pic packages, storing vehicles pictures for library menu.
73
3.2.5.6.5 RunPicContext
Figure 3.37 RunPic packages, storing the info and files for 3D game as well as images. 3.2.5.6.6 UnitPicContext
Figure 3.38 UnitPic packages, storing the images of the Game Enemy Unit, not in used since version v 1.0.54.
74
3.2.5.7 Video
3.2.5.7.1 javaContext
Figure 3.39 java packages, for the video files 3.2.5.7.2 JavaMediaContext
Figure 3.40 Java Media packages, for the additional Video files
75
3.2.5.7.3 javaxContext
Figure 3.41 the javax packages, for the video files 3.2.5.7.4 jmappsContext
Figure 3.42 jmapps packages, main package for the MPEG video player
76
3.3 3.3.1
Requirement Specification Non functional requirements

Description Priority
Requirements Copyright issues
This includes the images, audio and video files Very High downloaded from the web. This factor would be taken seriously in the project. Failing to do so would raise a big issue. If the sources were copyrighted, then an email would be sent to that particular company to get their permission in using their products with Academic and Personal License. This would also be a critical part for the project. It is Very High worth noting that the normal commercial software would take about 2 years to develop. However, this project only has 1 year to be completed. Based on this factor, the project has been started since year 2, giving it duration of one year and 3 months. The system needs to have an efficient memory usage. Very High Not only that, the system needs to have a support for large capacity of memory usage. This is an important factor in the project too. The system needs to have a fast running time on the High whole. It also needs to have a fast execution time, so as not to produce a slow movement.
Time
Memory
Speed
77
3.3.2
Requirements Video Player
Functional requirements
Description Priority
The system needs a Video Player that supports MPEG Very High format. This Video Player must have features that are available on the Commercial Video Player. The system needs to have a Sound Player. The Sound Very High Player should support WAV, MP3, AU, and TIFF format. This includes menu which is subdivided into buttons, Very High background images, animated images, and flash. This engine will provides all the 3D capabilities that Very High are needed in the 3D game. The system will load the map for the user to play. Very High
Sound Player
Menus
DX 3D Engine
Map Unit Editor
This feature provides the user with the ability of High creating an enemy unit, with a few choices given. This gives the user a 2D view of the 3D game when High played. The default key to activate this feature is M. High This gives the user choices of weapon when played. The user can select infantry weapon, as well as anti tank weapon. This gives the user the view of the player health, with High an animation of player conditions and a number showing the player health.
Map Display
Weapon
Health Bar
78
Object
This can be a Tank, Health Box, or an Infantry Unit.
High
Lighting
This feature gives lighting effect in a 3D game.
High
Scripting
This feature will enable the movement of Wall and Moderate Ceilings in the 3D game. This menu gives the user the choices of changing the Moderate settings for the game, which includes key mapping, video, and sound effects. The user can save the game by using this feature. The Moderate game will be saved in a file with SAV extension.
Option Menu
Save
Load
The user can load a particular game by using this Moderate feature. This menu gives the user an overview of the various Low units created in the game as well as some pictures of the vehicles in World War 2. This menu gives the user information about the system Low and the programmer involved. Extra features have been planned for Panzerlied song and famous quotes from World War 2 leaders as well.
Library Menu
Credit Menu
79
3.4 3.4.1
Some sample UI of the proposed System Menu
Figure 5.1.1 The main menu for the David War Game (version 1.0.0)
Figure 5.1.2 The Credit Menu for David War Game (version 1.0.0)
80
Figure 5.1.3 The Option Menu for David War Game (version 1.0.0)
3.4.2
2D Game
No UI available at the moment.
81
3.4.3
3D Game
Figure 5.3.1 A scene from the 3D game (version 1.3.15)
3.4.4
Miscellaneous
No UI available at the moment.
82
3.5 Design Choices for David War Game 3.5.1 Do and dont
During the analysis phase, the developer of David War Game has agreed on the following for the do and dont in the design of the system: (Subject to change) 1. The system will make full use of the memory available. The system must be able to make full use of the RAM memory available in the computer. It must not be able to run out of memory at the same time. Memory allocation will be based on the Java Heap Space. The amount of memory allocated to the system will be based on the Java XVM command interpreter. 2. The system will use the best available methods in the market. The most appropriate methods available in the market will be chosen in the design of David War Game. The choice of each method will be determined on the availability and complexities in design of that particular method. The speed of execution will be the main factor in choosing the method. Finally, the portability and possibility of implementing the method in the system will be the final criteria. 3. The system will have good game play and realism in it. The whole story of David War Game (except the 2D Game) must be strictly based on the World War II story! This includes the General of World War II, such as Erwin Rommel, the vehicles in the game, such as Tiger I Tank, and the scenario of the game, such as the event in the battle of Stalingrad. 4. The complexities of the system will be greater than those in the commercial games. David War Game will be more complex in terms of its library menu and thread processing capability. The developer of the system purposely implements these feature so that it could match the features available in commercial games. 5. The system will have features that are not available in the commercial games. Unit Editor, Enhanced Library Menu, and Plug In will be the special features in David War Game. Among these three features, Unit Editor and Enhanced Library Menu will be the features that are not available in the commercial games. The developer is proud to announce these features as part of David War Game. 6. The system will not have serious bugs in it. The system will be design so as not to have any obvious, permanent and frequent bugs in it. These include the key mapping, flickers and unwanted images in the system. 7. The system will not have unwanted termination and crashes. The system will not crash when some exceptions are caught. Instead, the system must adapt to it and take some corrective measurement to handle it. It must not be able to terminate suddenly without the users concern as well.
83
3.5.2 Current design methods in society

Most 3D Games in the society have a 3D Engine in it. Not only that, these Games are based on the First Person Shooter, due to the popularity it has recently. 3D technology is a must in the First Person Shooter Game Concept, while in the Strategy Game Concept this might be an optional choice. Many commercial games have attractive UIs and Interfaces in its system. Most importantly, all commercial games have good game play in it. In fact, a game without a good game play would not be able to survive in the gaming industry.
3.5.3 David War Game Design

David War Game will use the MP3, MIDI and WAV as its audio playing capability. In terms on Video capability, it will use the MPEG format. Like others commercial games, it will have a 3D Engine implemented in it. This 3D Engine will be named DX 3D Engine. It will use the BSP (Binary Space Partition) Tree concept for its environment creation. It will also have a parser to parse the OBJ and MAP file that are needed for the 3D Environment. All the system in David War Game will run concurrently, under the Thread Management and Processing control. (Refer to the implementation part for more details).
84
Part III: Implementation
85
Chapter 4 General Game Design

4.1 How The Program Works: Thread Processing
4.1.1 Java Threads
Sun Microsystem has developed a new type of system called Threads. This new feature has been available since JDK 1.1. As the technology progress further, Java Threads has since to incorporate with new features, such as Enhanced Thread Processing and more Thread Features. At the same time, some of the thread methods have been depreciated due to the securities issues that they poses when they are deployed (Such as the stop and wait methods). The thread methods that are being used in David War Game will be based on the Java JDK Library, version 1.4.1. David War Game makes full use of the thread processing capabilities, especially in its runtime dispatching capability. In fact, the system uses thread processing for its speed performance and memory usage. The algorithm for the system runtime performance is as follows: While(running){ Thread.sleep(someTime); runGame(); update(); } It has been suggested by some game developers that the system needs to sleep for certain amount of time every time it passes through the while loop. This is done in order to ensure that the game has some added realism in it. If the game would run without sleeping for some time, then it would results in a program that refreshes the screen every few milliseconds. This might results in some flicker to appear on the screen during the game play. So, the system must be implemented in such a way that compensate between high performance and high realism being achieve at the same time. An optimum value of sleeping time of about 10 miliseconds has been suggested for the optimum real time running of the system.
86
4.1.2 Synchronization
Java had provided the synchronization interface to deal with the critical section of a particular code. It provides two ways of synchronization, namely the block and method synchronization. Some part of the system needs to be synchronized, such as the screen, and memory allocation for the system. On the other hand, the users actions and enemy behaviors will not need synchronization to be implemented for it. In fact, it runs efficiently under the thread control rather than under the synchronization. So, it is expected that the programmer of the system knows when to synchronize a method or not. Synchronization is usually done when some resources must not be held by others such as the screen variable for painting when it is undergoing some update process. In short, the programmers are advised to do synchronization only when it was needed.
4.1.3 Threads Methods

Java Threads had provided some thread method, such as run, yield, destroy and wait, just to name a few. David War Game needs the run method frequently, as this method is the core method in Java Threads. Wait method will be needed when the system need to pause. In other words, the system can be suspended from normal execution if the user wants to take a rest after a long game play. Sleep method will be required when the enemy unit is idle, that is a condition when the enemy sees, and hears nothing. The system must not be able to encounter deadlock in case of failures, as well as having an unwanted termination during game play. Thus the core system unit in David War Game must be programmed and handle with care.
87
4.2
The Multimedia Aspect of The New System
4.2.1 Audio
Overview: During the analysis phase of the project, it has been agreed that the system in David War Game must be equipped with audio capabilities. This audio player must have support for MP3, WAV and if possible, other formats as well. However, the idea for developing User Interface for the Audio Player has been ruled out, due to its insignificant role in David War Game. Advanced features, such as loop back playing capability, will be considered to be implemented, if time permits.
4.2.1.1
4.2.1.1.1
Player
MP3 Player
The MP3 audio player developed for the system is based on the software developed by the javazoom community. [Refer to the reference under the audio section] The javazoom video player is available freely to the open source community, and is licensed under the GPL (General Public License). A version of the audio player with GUI (Graphical User Interface) is also available, with the name JLGUI (JLayer Graphical User Interface). During the implementation phase of the project, this audio player has been enhanced further to support the capability of loop back playing. A more efficient algorithm for thread management has been integrated into the audio player so that it can adapt well to the system being developed. This is done by settings a different parameter for the javazoom audio player. (visit http://www.javazoom.net). 4.2.1.1.2 WAV Player
The WAV audio player developed in the system is based on the packages available in the Java JDK Library. Some sources for the audio player, particularly from the Deitel Programming book, written based on the Java JDK library, has been taken into account to be incorporated into the system. However, this audio player has been modified to support real time environment that is needed in the system. Audio Player Code from Game Programming books such as Developing Games in Java by David Brackeen has been referred to as well to determine the possibilities of implementing it in the system. 4.2.1.1.3 MIDI Player
The MIDI audio player coding is taken from the book published by David Brackeen (Developing Games in Java). The MIDI audio player will be implemented for the 2D Game, where the complexities of that system will not be as high as those from the 3D Game. The MIDI audio player has the ability to adjust the sound level, as well as adding some noise and special effects into it. By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 88
David War Game Final Report Final Year Project 2004/05 4.2.1.1.4 Other Players
The Audio Player in David War Game has support for other format as well, such as AU, and AIFF. However, due to the popularity of these audio formats, the system does not really need to have this feature in the first place. So, this feature is given minimal consideration when implemented.
4.2.1.2
Decoder
For the audio player, the audio format of MP3 and MIDI need a decoder as the file with this format is compressed by nature. MIDI file compression is a lot more compressed compared to the MP3 file. However, the decoder for these two files format needs to be implemented in a different way and fashion. For MIDI file, the Java JDK library has provided a set of components to deal with the decoder of the MIDI file. Unfortunately, the Java JDK library dose not seems to provide facilities to deal with the MP3 file decoder. However, it is fortunate that the freeware javazoom packages had implemented a set of functions for the MP3 decoder. In fact, it is specially design to deal with the MP3 file functionalities. For other file formats such as AU and AIFF, there is no need to implement the decoder as the system does not rely heavily on these file format. (In fact the system does not use AU and AIFF file format for its audio capabilities).
4.2.1.3
Converter
Some game programmers preferred to use WAV file format for their system audio capabilities as it is fast and efficient compared to other file formats. In fact, WAV file format is supported by most of the Audio Player. On the other hand, some game programmers preferred to use MP3 file format as their choice as its saves disk storage space. To compensate for these two factors, an implementation for converting the MP3 to WAV files format need to be done. This feature must also be able to reverse the process, which is to have the capability to convert WAV to MP3 files format. Fortunately, the javazoom packages provided the functions to convert MP3 to WAV file format. Moreover, there are many freeware audio converters software available in the Internet that can also perform this conversion effectively.
89
4.2.2 Video
Overview Like many commercial games, David War Game needs Video Player as part of its video capability. Most commercial games have support for BIK Video file, with few of them having support for MPEG file format. David War Game will have a video player that supports MPEG format, due to the file simplicity in design and structure. (The file with MPEG can be played by many commercially available softwares). However, it was agreed that the design of the video player must be simple and attractive as well. This video player will be used only during the start up, due to the limitation of the software used.
4.2.2.1
MPEG Player
David War Game will only support the format of MPEG for its video player, therefore other video formats such as MOV and BIK have been ruled out. So, during the analysis phase, many video players have been search throughout the Internet. Some, such as Quick Time Player, is available in commercial license and is not portable towards the system developed, while others Video Player such as Sure Player are simple but is freely available at the same time.
4.2.2.2
The JMStudio
The system in David War Game uses the JM Studio Video Player during its initial phase. JMStudio is a video player that is developed by Sun MicroSystem, and is available freely under the GPL (General Public License) license. However, the JMStudio does not really seem portable towards the system and poses some technical problem during the initial stage. It is no doubt that the JMStudio has many interesting and attractive features, but some of it may not be useful for the system developed. (Such as the player for the connection through the URL). Moreover, it is hard and times consuming to modify and restructure the code in order to suit the system as the files given by Sun Microsystem is too big in size. (visit http://java.sun.com)
Figure 4.2.2.2 The JMStudio By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 90
4.2.2.3
License
It was agreed that the copyright issues in David War Game be given the top most priority during the project timeline. This suggestion includes the Video Player being developed, as well as its Video Files (extension MPEG or MPG). Since the JMStudio has portability and compatibility problem for the system developed, an alternative needs to be sorted out to find another video player. At the same time, this video player must be available freely, like the JMStudio, typically under the GPL (General Public License) License. On the issues of the Video Files, the system needs a War Game video file, which is available freely at the same time. However, it is very difficult to find this particular video files in the Internet, as most War Game video files are commercially available. Thus, some compromise and consideration need to be done on this particular issue as this might breach the copyright issues.
4.2.2.4
The Freeware Sure Player
It is fortunate that there are some freely available Video Players that supports the MPEG file format in the Internet. This video player, named Sure Player, will be able to replace the JMStudio Video Player while providing all the basic necessities given by JMStudio at the same time. Moreover, it is relatively easy to configure and change the coding of the player in order to suit the system. The Video Player can also adapt easily to the system. However, there are still some remaining bugs that need to be eliminated in the coding of the Video Player. Besides that, the Video Player consumes more memory space compared to the JMStudio. In short, no doubt that the Sure Player has some specific problem in it, David War Game will adopt the Sure Player for its Video Capability due to its simplicity and portability in design structures.
91
4.3
General Design Structure of The 2D And 3D game
Overview The system needs a memory space of about 400MB (Based on RAM (Random Access Memory) Specification), while the graphics requirement will be 16MB (Recommended 32MB). An amount of about 100MB of hard disk space will be needed to install the system. The system needs an audio card as well, preferably the SoundMax audio card.
4.3.1 2D Game
4.3.1.1 Memory management
Before the implementation phase of the project, it was decided that the system being developed will have support for 3D Game only. However, due to the small size and complexity of the 2D Game, it was agreed that the 2D Game implementation will be added into the project as well. The initial proposed memory consumption for the 2D Game was set to 3.5MB (based on the RAM (Random Access Memory) specification). When the 2D Game has been developed, it was found out that it only consumes 3.2MB of memory. There was additional 0.3MB memory leftover in the system and this could compensate for the high memory demand by the 3D Game. However, as the time goes along, the complexity of 2D Game has become even larger. Not only that it was being more complicated in terms of size, but it was more complicated in terms of task management as well. The audio player has been enhanced further to give more support for Threading and Multi Task capability. It has also been enhanced further to support loop back playing as well. Furthermore, there was more enemy unit created in the 2D Game. Based on this upgrade and enhancement, the new 2D Game needs a memory amount of 4.2MB, an additional 0.7MB compared to the initial proposed memory consumption. No doubt that the 2D Game took more memory, it was still at an acceptable level. Therefore, the final memory consumption for the 2D Game was set at 4.2-4.3MB, which still does not overburden the 3D Game Running Capability.
92
4.3.1.2
Component
The 2D Game will have a non continuous background images, serves as the 2D environment display. It will have a hero unit in it, given a name of Eri. For the enemy unit, it will have the soldier, tanks and aliens as well. All the enemy units will be in animation mode, with a frequency rate set by the game programmers, using the value of 500 miliseconds as the default value. There are two types of components in the 2D Game, the static and non-static components. The static component will be those components that cannot move, while the non-static components will be the moving components. Examples of static components will be the tile, while the non-static components will be the player, enemy and pick up item.
4.3.1.3
Sound and Video
There was no video player for the 2D Game, as it was not needed in the first place, due to the simplicity in the 2D Game design. However, there is audio player for the 2D Game. This audio player will be coded based on the javax.audio packages provided by the Java Library. It will have a support for MIDI file format only. The coding for the 2D Game will be based on the work developed by David Brackeen, who published the book, Developing Games in Java. (visit www.brackeen.com/javagamebook)
93
4.3.2 3D Game
4.3.2.1 Memory management
RAM Memory As has been expected, the size and complexity of the 3D Game will be much bigger than the 2D Game, not only in terms of size, but memory and design effort as well. During the analysis phase of the project, it was agreed that the 3D Game memory consumption will be around 128MB, based on the RAM (Random Access Memory) specification. In the initial phase of the project, the 3D Game being developed consume a memory amount of about 152MB, an increase of 24MB (18.75% increase). However, as the project progress further, the complexity of the 3D Game has began to grow. When the 3D Game has been equipped with an advanced audio player, it took an extra of 5MB of memory spaces. This was made even worse when the 3D Game needs to support multi threaded audio playing capability, where a new and drastic change to the implementation of the audio player need to be done. This has cause a further increase of 15MB of memory spaces. It was suggested that the 3D Game needs to support the Video Player in between the Game Play, so as to enhance the realism of the Game, but this attempt was unsuccessful as the memory consumption has been increased by nearly two fold for this to be made possible. In fact, Java Run Time environment cannot really support the big memory amount for this implementation to happen in the first place. When the 3D Game implementation has been finalized, it was found out that the memory consumption has increased by many folds, from the initial value of 128MB, to the final value of 386MB. Due to this factor, it has been suggested that the user who wanted to use this system must have a minimum amount of 512MB memory in order to play the game. Furthermore, because the memory consumption was extremely huge, it was proposed that the whole Java Coding of the System to be converted into machine code equivalent, so as to boost up the speed by 8 times. (Machine Code runs 8 times faster than the Java Equivalent Code). Graphics Memory The author of this report recommended that the user computer system must have the graphics card of a well known manufacturer, such as the ATI Radeon, Ge Force, and Intel Extreme Graphics. However, the system does not really need a powerful graphics card, as the graphics in the 3D Game is too basic and simple by nature. It was recommended that the user must have an equivalent 32MB of graphics memory, while the 16MB graphics memory will be the minimum requirement. The system would prefer to have a support for dedicated memory, so as not to lower down the running speed.
94
4.3.2.2
Component
First of all, the 3D Game needs a 3D Environment to be created before playing the game. This 3D Environment will have a set of walls, ceilings, floors, stairs and doors. The 3D Environment will be developed in cubical format, where the environment being developed will be in cubic form, with no curving surface for the environment. After the environment has been created, the map needs to load in all the objects into the 3D environment. As in the 2D Game, there are two types of objects, the nonstatic and static objects. Objects can be considered as some life form that exists in the map, with the capability to perform some functions, and listen to some events. (For example, when an enemy unit is hit, the enemy life will be decreased by certain amount) To simplify the coding effort in the 3D Game, the implementation of the 3D Environment and Objects will be done in a file with specific extension, such as .map and .obj. To be able to manipulate this file and perform the necessary functions, a parser will be developed to parse this file and organize it into certain structures and formats. Therefore, there is a need to provide a standardized format for the map and obj file. (Refer to the Map and Objects sub chapter to get more details). Additional components that need to be implemented in the 3D Game will be the Game Scripting and the Map Display. Game Scripting is done to perform the special effects of a game, such as Opening a Gate in a Castle, besides providing more efficient running time for the system. Map Display will provide the user a view of the 3D Environment in 2D Environment (Top View).
4.3.2.3
Sound and Video
In terms of audio capability, the 3D Game Audio Player will have support for the Audio File Format of WAV and MP3. It will use the javazoom freeware packages as its MP3 audio player (Also Known as JLayer). For the WAV file format, it will use the existing library functions provided by the Java JDK library. The JLayer MP3 Audio Player, however, has been upgraded further to support for loop back audio playing capability as well as multithreaded playing. For the Video capability, the 3D Game uses the JMStudio Player as its Video Player. However, there exists a freeware SurePlayer available on the Internet. No doubt that the SurePlayer has some minor bugs and performance problem compared to the stable version of JMStudio, it was more portable to the 3D Game. However, the Video Player will be played during the start up of the game only. (visit http://rnvs.informatik.tuchemnitz.de/~ja/MPEG/HTML/mpeg_tech.html for more information on the SurePlayer Video Player)
95
4.3.2.4
The DX 3D Engine
It is no doubt that every 3D Game must have a 3D Engine to support the running of the game. For David War Game, the system will have DX 3D Engine to run the system. This 3D Engine will have support for 3D Graphics Manipulation, 3D Graphics Rendering, Lightings Effect and the Speed Execution as well. The section that describes the 3D Engine has been separated into few sections, due to the complexities imposed by the 3D Engine. (Refer to Chapter 8 for more information). However, the 3D Engine developed will be a simple one, and will not be as good as those locally available commercial games, due to the programmers experience level in the Gaming Industry. The 3D Engine will serve as the primary task management to manage the 3D Environment as well as the 3D Objects in the 3D Game. Due to the poor speed capability provided by the Java Programming Languages, the 3D Game will perform the basic 3D Functions only, which restricted the realism effects in the 3D Game.
96
4.4
UI Design
During the analysis phase of the project, several proposals have been given to the design of the UI (User Interface). The design of the UI, will be based on several factors, and are as follows: 1. 2. 3. 4. 5. Cool Background Images Efficient Running Time To Display That Particular UI. Cool Components For The UI. Detailed UI. Simple But Attractive.
When the above factors have been considered, several drawbacks and advantages of each factor were considered into great details. Finally, decision has been made on the design of UI. The specifications are as follows (These specifications are to compensate for the most optimum speed and attractiveness): 1. The UI needs to have nice and cool background images. 2. The UI needs to have low, if not, moderate speed to display it in the system. (Although some Library Menu UI in the game has relatively slow speed). 3. The UI needs to have cool, attractive, but simple components in it. 4. Details of the UI will be moderate only. 5. UI design will be made to be simple as possible, but attractive at the same time, to compensate for the speed of execution. Definition of menu: Basically, a menu should have: 1. 2. 3. 4. 5. A Background Image. A collection of buttons. A Panel. Additional elements such as player, version number, and status. In a full screen mode.
97
David War Game Final Report Final Year Project 2004/05 See figure below for a description of menu.
Background Images
Buttons
Panel
Player
About Animation
Figure 4.4: A menu
98
4.4.1 Background Images

Several issues have been raised up about the background images that need to be incorporated into the system. Copyright of the background images, will be the most important issues regarding the background images. Most of the background images have been taken from the Game Developers websites, such as the www.panzers.com. Some, but not all, of the background images are copyrighted. So, in order to deal with this problem, several actions have been taken, below are few of them: 1. The system being developed will be under the terms of Fair Use of the Copyright Law. In other words, the program developed will be for academic use only. 2. Since it is under the Academic Use Only, the program will be developed for demonstration during the open day, and serves to help the author of this report in his Final Year Project. No additional copies of the program will be distributed to others, besides the supervisor, the university, and the beta tester users. 3. All copyright material will be acknowledged and referenced in the report of the Final Year Project. 4. The Background Images will be changed and modified for the system. 5. If the programmer still unable to solve all the above, the background images will be discarded and a freeware sources will be obtained instead to replace it. The Background Images must be related to the event in World War 2, so as to enhance the realism effect in the game. Besides that, the size of the background images must not be too big, so as not to burden the system performance. (For example, the loading time for the menu).
4.4.2 Buttons
It was lucky enough that the buttons being developed for the system do not have copyright issues in it. However, some problems still exist for the design of the buttons. First of all, the buttons provided by the Java Library is too simple in design and not attractive enough. In other words, the buttons for the game will be design from scratch, starting from the Components Class of the javax.swing package. The images for the buttons will be drawn by the programmer, and will be added into the buttons. The buttons being developed will have the following characteristic when called: 1. The button is translucent, that is the button is visible to itself as well as the background images. (see figure 4.4.2 for more details) 2. The button will become brighter when chosen. 3. The button will produce sound upon selection. 4. The button must be stable towards the system. (Not a must). By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM 99
Figure 4.4.2: A translucent button
4.4.3 Sound Effects

Initially, the buttons developed will just invoked the Action Listener when selected. For version 1.0.7 and above, the system will have a button that produces sound effects upon selection. This sound effect is taken from a free source domain. (A game developed by Andre La Mothe, who published the book Tricks Of The Windows Game Programming).
4.4.4 Animation
For every menu, there will be an animation of a player that was wearing a sunglass. This player objects serves as debugging purposes during the project implementation phase. It can be seen that this player is actually an animation. The animation in the UIs will be implemented as a collection of images. These images will be changed every 100 miliseconds. Due to the way human eyes perceives motion, this collection of images will form a continuous moves of an object, like an animation.
4.4.5 Other Components

Other components in David War Games are such as Text Display on the Screen about the Plug In Status, and the Flash Feature of the Version of the Game.
100 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
4.4.6 Key and Mouse Handling

All the key and mouse handling in David War Game will be handled by one class, the InputManager class. This class will register all the event and listener of a particular keystroke and mouse click. If a component has been created and wants the system to listen to it, it must first register its event with the InputManager, by calling the method, Component.addListener(inputManager); It is in the InputManager class that the background images are handled as well. When a new menu is chosen, the background images will be changed as well, by invoking the listener from the button and change it in the InputManager class. During the intermediate phase of the project, it was found that the Key and Mouse Handling in David War Game seem to suffer from permanent and serious bugs. The programmer taught that problem was a minor one, so it was left over until the final phase of the project. During the final phase of the project, the programmer tried his best to fix these potent bugs. After countless hours and days, the bugs were finally removed, but there exist another, transient and minor bugs in the system (These bugs affect the key and mouse handling as well). Due to the minor bugs present in the system, the programmer finally decides to enable the key and mouse handling, but gives the system a sub standard function for the key and mouse handling instead.
4.4.7 The Library Menu

In David War Game, there is a special menu called Library Menu. It is in this menu where all the interesting and attractive things are located. There are animation of weapons, tanks and aircrafts, besides the details about the enemy unit in David War Game. (See the figure below about the Library Menu).
Figure 4.4.7 The Library Menu
4.4.8 Discussion on several developed UI:

Below are some descriptions on the UIs being developed in David War Games.
4.4.8.1
About menu
About
Text Animation
Figure 4.4.8.1 About Menu This menu gives the user about the programmers involved in the project. It has a animation of text when invoked.
4.4.8.2
Loader menu
Loader Text
Loader
Figure 4.4.8.2 Loader Menu This menu will load the game upon invoked. When loading a game, a text will be displayed to tell the user to wait while waiting for the system to be loaded.
4.4.8.3
Configuration menu
Setting Menu
Settings Panel
Figure 4.4.8.3 This menu will give the user to configure their settings, such as key and mouse mapping, as well as the audio settings.
Chapter 5 2D Game Design

5.1 Single Player Game Design
Overview The 2D Game will be implemented based on the Adventure Game Concepts. (A player that moves in a 2D Environment, where the player can jump, shoot, attack and move in any x-y direction).
Figure 5.1: The 2D Game in David War Game
5.1.1 Memory unit

The memory unit for the 2D game will be located in the ResourceManager class (package com.brackeen.tilegame). It is in this class that all the resources and memory are located. Among few resources that are managed by this class are the tiles, the background images, the player, the enemy units, the goal, the power up, the boundary, and the points. This class also manages the memory consumption of the 2D Game, by allocating and relocates the memory. This is done by having remove and add methods. It is in this class where the mirror images of the objects (such as player and enemy) are being created. Mirror images are useful when a player is moving in the opposite direction. Besides that, mapping of image files to the 2D Game are also performed, by using the filename and map it to the position specified by the programmers. 106 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
5.1.2 UI
There are several UIs being designed for the 2D Game. Before starting the game, the system will provides a UI for the user to choose whether he wanted to proceed with a new game or cancels his action instead. A load UI has also been designed for the 2D Game. Unfortunately, the 2D Game is too simple in design, so the load feature has been pulled down eventually. There is even a suggestion to provide an interface for the UI before the user exit the 2D Game. This was however, like the load feature, pulled down as the 2D Game does not really need it. The 2D Game needs very few UIs as it is not complex, as there is not much functionality to deal with it. Finally, there is a setting UI allocated for the 2D Game, where the system has allocated some features to deal with its audio player and the key mappings as well.
5.1.3 Player
Figure 5.1.3 gives the player icon. The 2D Game will have a hero in it. This hero is given the name Eric. This hero will have to search through the environment, trying to find a goal in order to proceed to the next level. At the same time, the hero can defeat its enemy unit by stepping on top of it. Note that the heros icon has a gun on his hand. However, the hero cannot fire his gun, due to the time constraint given in the project, and the factor that the game needs to be simple at the same time.
Figure 5.1.3 The Player (Hero) Icon
5.1.4 Enemy
General Rule For The Enemy Unit Below are some lists of the enemy units characteristic: 1. 2. 3. 4. 5. Every enemy unit will not be affected by gravity. Every enemy unit has its own capability, such as the ability to walk, and fly. Every enemy unit cannot think in depth, such as detecting the player. Every enemy unit has its own boundary, such as height and width. Every enemy unit will have its own mirror images, like the player.
Enemy 1: Soldier The soldier is perhaps the stupidest enemy in the 2D Game. The soldier will just walk through the map, without even noticing what is happening in the environment. If he stumbles upon a hole, he will just step into the hole. (This show how simple is the 2D Game, and the relatively low AI (Artificial Intelligence) for the soldier). Whenever he meets an obstacle, he will move in the opposite direction. Figure 5.1.4.1 gives the overview of a soldier icon.
Figure 5.1.4.1 A Soldier Enemy 2: Alien Unlike the soldier, an alien can fly. Besides that, an alien has more area coverage, thus the player will find it hard to defeat it. Furthermore, an alien can fly, a gift that the soldier is lack of. Due to the alien ability to fly, it is harder to defeat the alien, as it restricts the player movements. An alien is also more lasting than the soldier, as it would not drop into hole when move. Like the soldier, an alien will move into the opposite direction when it stumbles upon obstacle. Figure 5.1.4.2 gives the overview of an alien icon.
Figure 5.1.4.2 An Alien
David War Game Final Report Final Year Project 2004/05 Enemy 3: Tank A tank behaves like a soldier. In fact, it is as dump as the soldier. Unlike the alien, a tank could not fly. On the other hand, a tank could not be killed. It is also bigger in size, thereby the players movements is restricted in some way. A tank is the most potent enemy in the 2D Game, given its capability. However, due to the time constraint, the tank is unable to be implemented in the 2D Game at the moment.
5.1.5 Map
Every time the 2D Game has been loaded, the system would read a file to load the map. This map file, must have a specific format that is understandable by the parser in the system. The file below shows an example of a map file in 2D Game. # Map file for tile-based game # (Lines that start with '#' are comments) # The tiles are: # (Space) Empty tile # A..Z Tiles A through Z # o Star # ! Music Note # * Goal # 1 Bad Guy 1 (grub) # 2 Bad Guy 2 (fly) o ooo IIIIIII ooo IIIIIII o o o o o o o 2 o o o 2
2 2EF EF EGD EF 1 CD 1 1 EGAD * BBBBBBBBGHBBBBBBBGHBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBGA AHBBBBBBBBBBB The space, as specified in the document, will represent the empty tile in the 2D Game. This tile will be marked as null. There are 9 combinations of tiles in the 2D Game, marked by letter A-I. There are also 3 special icons in 2D Game, o for star, ! for music note, and * for goal. The enemy unit will be represented as 1 and 2 respectively, with 1 for soldier and 2 for alien. (Note that 3 for tank were missing as this was not implemented due to the time constraint).
5.1.6 Tile and Collision Detection
Figure 5.1.6.1: Tile 1
Figure 5.1.6.9: Tile 9 Figure 5.1.6.1-5.1.6.9 shows the different tile available in the game. It is with this tile that the collision detection is performed. Therefore, when the tiles were loaded into the system, this tile will be marked. Their position will be noted as well. When the player stumbles upon this position, the player will not be permitted to pass through it. For the enemy unit, they will move into the opposite direction, after setting up their mirror images. Every location of the player, enemy units and tiles will be saved and set when the system load the map, therefore the system will be able to handle the collision. However, the location of the player and enemy units will be dynamic and relative to the environment instead.
5.2 Extension to Online And Multiplayer Gaming

Overview: Some analysis has been made into the possibilities of implementing the 2D Game onto online and multiplayer gaming. The analysis has been made by looking into some other equivalent games on the web in terms of platform dependencies and features. Initial feedback of this analysis shows that it is feasible to incorporate the 2D game online. In fact, there are some available free source codes online that does all this jobs and is licensed under the GPL (General Public License). On the other hand, there exists one problem on how to implement the game in order to be available online. Several suggestion are given, which are as follows: 1. Made the 2D Game in Applet form and distribute it via Applet Command. Perhaps, this is the simplest way to implement, and does not incurred much overhead. However, for the user to be able to play the 2D Game, the server that the game was in must be able to support Java. Besides that, the users must have Java Platform to be able to view the game. This restriction will let some of the users unable to play the game, if their browser does not support Java Run Time Environment. 2. Distribute the 2D Game in Java Web Start. This method will be more complicated than the previous one, and like the previous method, some users will not be able to play the game if their browser does not support the Java Run time Environment. 3. Make the 2D Game into Exe format, and play the games via the TCP/IP link. This method is not really efficient, as additional software need to be purchased in order to perform the conversion. Based on the above three factors, the 2D Game will be distributed via the Java Web Start, as some game programmers have been using this method recently.
5.2.1 Overview of the Multiplayer Game Concept

A multiplayer gaming concept enables multiple players to play a game at the same time. However, some games require the players to switch their turn to play the games, while some requires the players to play online at the same time.
5.2.2 Studies on Multiplayer Game Concept

A multiplayer game concept is best played when the users have access to a broadband communication link. If the user has dial up or modem connection, then the user will be at a disadvantage. Multiplayer game concept requires a high speed connection as the packet containing the game state and info needs to arrive at the players site in order to update their game status. This is further made worse for a game that runs in a simulation mode (Game that keeps on updating itself every few miliseconds), like the 2D Game in David War Game. The multiplayer game concept also needs the data to be transferred through the TCP (Transmission Control Protocol) layer, as lost in information will lead to unstable states of the game. Connection through the UDP (User Datagram Protocol) might give the player a fast response time and transmission speed, but UDP does not guarantee packet delivery. Therefore, TCP will be the preferred choice of packet transfer, but it still lacks of response time and transmission speed in general. There is another problem associated with multiplayer game concept, the connection to other users on the internet. It is no doubt that the player that wishes to play with other players will have to sort out a way to communicate with other player. He must be able to know what the other players IP (Internet Protocol) address before starting the game. Besides that, he must also know that the other players are interested in joining the game in the first place. However, this problem can be solved by connection spooling through the TCP/IP (Transmission Control Protocol Internet Protocol) layer.
5.2.3 Implementation on David War Game

No doubt that it was found out that implementation of online and multiplayer gaming is feasible for the 2D Game, the 2D Game will not be made online for the following reasons: 1. Time constraint The online gaming feature has been allocated in the second semester. The programmer of the 2D Game has no time to implement this, as there are some other features which are more useful to the system that need to be implemented urgently. 2. Copyright issues. The 2D Game has been written under the Fair Use Concept of the Copyright Law. Therefore it is intended for academic use only, and the software should not be distributed to anyone besides the supervisor, university, and beta tester. 3. The size of the 2D Game. Multigaming concept is only feasible if the file size is not too big in the first place. As the time goes, the complexity and size of the 2D Game has begun to grow larger. This indirectly makes the 2D Game unable to be made available online.
5.2.4 Java NIO interface

The Java Programming Languages has provided an interface that dealt with the multigaming concept. This is known as the Java NIO (Network Input Output) interface. No doubt that this packages provides a lot of functionalities for the multigaming capability, the 2D game will not be made available online because of the previous reason.
5.2.5 Implementation on J2ME technologies and devices

Some users want the 2D Game to be available on the wireless and mobile devices. There is one possibilities to incorporate into the devices, that is by using the J2ME (Java 2 Micro Edition) Technology. However, the developer of the system encounters some restriction and limitation to incorporate the 2D Game into these wireless devices. First, the developer lacks the experience in using J2ME technologies. Secondly, the 2D Game requirements are quite high, and might not be supported by the wireless devices, such as the audio player. Finally, the size and memory requirements of the 2D Game might not be suitable for the Wireless Devices. So, this suggestion was drop out eventually.
Chapter 6 Graphics and Environment in 3D Game

6.1 Graphics in 3D
Overview Basically, a graphics can be defined as a set of colors that are applied to the computer screen. This can form a line, a curve or more complicated objects, such as a house. A different combination of graphics will form some interesting features, such as morphing, just to name a few.
6.1.1 Basics of Graphics

There are some basic fundamentals of using graphics. First, the programmer must know how to apply some specific color to the graphics. He must also know the attribute of graphics, such as the length, intensities, and refresh rate of the screen. For the 2D Graphics, the user need a very basic knowledge of math, and need to understand the representation of coordinate in the X-Y plane only. He must also need to know about the relative and absolute position of a coordinate. However, to learn about 3D Graphics, the user must know a lot more than the 2D Graphics. Not only that the 3D Graphics are much more complicated, the user must be able to manipulate coordinate in the X-Y-Z plane. He must know about some math basic, such as Matrices, Transformation, and Normal, just to name a few. Besides that, the programmers maths knowledge must be very good, and his debugging capability must be very good as well, as the debugging of the 3D Graphics will be very tedious and cumbersome. The next section of this chapter gives an overview of the math fundamentals that a programmer must have in order to do the 3D Graphics Programming.
6.1.2 Math Fundamental

6.1.2.1 Vector
A vector consists of a direction and magnitude. The relationship between the magnitude and direction is given by Direction=|magnitude|; Let the two vertices joining a line be (x1,y1,z1) and (x2,y2,z2) respectively. The magnitude given by the line will be: Magnitude=((x1-x2)2+(y1-y2) 2+(z1-z2) 2) The direction will be given by |Magnitude| (Absolute of the magnitude)
6.1.2.2
Matrices
A matrix consists of a collection of rows and columns. For the 3D Game, the first row will be given index 0, the last row index (n-1), the first column index 0, and the last column index (m-1), where n is the matrix height, and m is the matrix width. When reading a matrix, it was read column by column first, then row by row. A matrix can be a square matrix, as well as a rectangular matrix. Matrix can be applied to the coordinate of objects position in the game. A matrix can have two planes only, the X-Y plane. Thus, it is biplane in nature. It is also possible to construct a 3D matrix, but this matrix can made the life of the programmers more difficult as it is more complicated in terms of design. Every position in matrix is assigned a coordinate. So, to reference a position in a matrix, the value of the row and column position must first be obtained. It is also possible to construct a triangular matrix, by setting the symmetrical position of a matrix to be zero. |0 1 2 5| |0 0 1 3| |0 0 0 4| |0 0 0 0| A triangular matrix
6.1.2.3
Transformation
A transformation can be defined as a process of converting one object into another object. There are many type of transformation, with the rotation, translation, shearing, and scale being the most common one. In David War Game, the translation, rotation and scale will be use the most. Scaling equation: |X2| |X1*s1| |Y2| = |Y1*s1| |Z2| |Z1*s1|
Figure 6.1.2.3.1 Scaling Equation Rotation equation: |X2|=| cos(t) -sin(t) | | X1 | |Y2| |sin(t) cos(t) | | Y1 |
Figure 6.1.2.3.2 Rotation Equation
David War Game Final Report Final Year Project 2004/05 Translation equation: |X2|=|X1|+|a| |Y2|=|Y1| |b|
Figure 6.1.2.3.3 Translation Equation Scaling is used to represent an object at a specific instance. If the object is far away, then the object is scale to a smaller size. If it is very close to the player, then it is scaled to a bigger size. Rotation is used to turn an object viewing angle to some new position. If the player is facing other side, then the rotation is applied to the player at that specific angle. Translation serves to move one object from a position to another. The coordinate of movement will be X-Z in the 3D Game, not X-Y, as the Y plane represents the height of the map, not length or width.
Figure 6.1.2.3.4 Scaling Diagram
Figure 6.1.2.3.5 Rotation Diagram
Figure 6.1.2.3.6 Translation Diagram Homogeneous Coordinates Some of the transformation matrices are 2X2 matrix, while some are 2X1 matrices. This will cause some problem in the calculations of multiple transformations. The 3D Game needs multiple transformations in order to make the objects moving in a 3D Environment. Therefore, the matrices need to be standardized in order to perform this multiple transformation calculations. There exist methods whereby all the transformation matrices can be converted into 3X3 matrices. The method is known as homogeneous coordinates. A homogeneous coordinates is assigned so that the equation X=X1*h; Can be formed, where the h is a constant. Usually the homogeneous coordinates is assigned the value 1. By using the homogeneous coordinates, the equation of a transformation will be standardized and easier to be performed. 119 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
6.1.2.4
Normal
Another aspect of application in 3D graphics will be the normal of a line. 3D Graphics need to perform normal to check for the collision detection. Normal of a line is useful in collision detection as it can check for interception of a line with another. If the line is intercepted then it is for sure that the two lines collide with each other.
Figure 6.1.2.4 A normal of a line, useful in collision detection
6.1.2.5
Coordinates and vertices
A Vertex has a set of coordinates, X, Y, and Z. A Vertex stores the coordinate of a particular object. Vertex is important in determining the position of an object. For a 3D Game, there are 3 planes, the X, Y, and Z plane. Each particular coordinate in this space is represented by one vertex, with coordinate x, y, and z respectively.
Figure 6.1.2.5 The 3D Space, with X, Y and Z plane
6.1.3 Polygon Structure

A polygon is a set of vertices with its own distinct coordinates, and forms a cycle of vertices. (more than 3 vertices connected to each other). This combination of vertices will form a polygon, with triangle for 3 vertices, rectangular for 4 vertices, pentagon for 5 vertices and so on. A cube can also be constructed by defining 8 distinct vertices that are connected to each other.
Figure 6.1.3.1 A 2D Polygon, Rectangular Polygon
Figure 6.1.3.2 A 3D Polygon, A cube
6.1.4 Camera View

A view from the player can be considered the camera view. All the objects that are view by the player will have a coordinates that are relative to the camera. Camera view can have many resolutions, with 800X600 and 1024X768 being the most common one. A camera view can also be reduced and enlarge at the same time.
Figure 6.1.4 A camera view in David War Game version 1.0.5
6.2 Texture Mapping and Lighting

6.2.1 Overview on Texture Mapping And Lighting
As an object is constructed, it needs color to fill into the polygons. Some objects need only a simple color, a one tone color, while some objects need a more complicated color, like some mixture of colors. On the other hand, objects such as trees and walls need a camouflage type color. Problems arise as how to make this complicated color. For a simple one tone color, it was for sure that the graphics library can easily do this. The answer to this problem lies in the concept of texture mapping. A texture is a set of symmetrical images that have a complicated combination of color and usually stored in an image file format such as PNG (Portable Network Graphics). Refer to the next section on more details Texture Mapping Definition. Figure 8.2.1.1 shows an example of texture mapping. Lighting is done in a 3D Environment so as to enhance the realism effect in the environment. Lighting usually has the attributes of intensities and cover area as part of its implementation. (See figure 6.2.1.2 for a concept of lighting)
Wall Mapping
Object Mapping
Floor Mapping
Figure 6.2.1.1 Texture Mapping in a 3D Environment
Figure 6.2.1.2 A concept of lighting
6.2.2 Simple lighting

A simple lighting will have only intensities and coverage area as part of its function. Intensities is defined in unit of pel, a quantity of light intensities. A pel value of 200 will give a slightly shaded area, while pel value of 10 will give a very dark area. (Almost all the area cannot be seen by using this value). A very high pel value, such as 4000, will give a very bright area, with all the area being exposed. However, there is some limit on the upper bound value, where there will be no obvious changes when the value exceeds this value. The coverage area can be defined in terms of radius, with 200 being the default value. Usually, the programmers want to define a lighting that covers an area of 250 radius yard. So, they will place lighting in between every 600 lines. Lighting is usually place on top of the ceiling, with 50 lines below the highest ceiling. However, lighting cannot be put outside the ceiling, as the game will not show the effect of the lighting beyond this bound. (See figure 6.2.2 for more details)
Figure 6.2.2 How lighting should be done
6.2.3 Advanced lighting with shadow effect

A more advanced lighting can be implemented based on the previous lighting concept. This is known as lighting with a shadow effect. Lighting with shadow effect will enables the object having its shadow shown upon facing the light. This can be implemented by calculating the distance between the object and lighting position. There is also a need to calculate the viewing angle between the object and the lighting. (Using the tangent functions). The objects need to provide the height and the lowest position of its boundary for the shadow to be created. (See figure 6.2.3 for more detail)
Figure 6.2.3 Lighting with Shadow Effect
6.2.4 Several concepts for lighting

There are several key concepts of lightings. Below are few of them: 1. Lighting can be done for a room. In this case, the lighting will be applied for the whole room. Normally this lighting will be positioned on top of the ceiling. 2. Lighting can be given to a room, but from a specific source, such as lamp post. This kind of lighting will normally be placed at the side of the wall, where a lamp will be fixed to the wall. This lighting is more realistic compare to the previous one, and usually applied to an environment inside a building, such as a castle. 3. Lighting can be coming from the natural sources, such as the Sun. This kind of lighting will have great intensities (pel), and usually covered a vast amount of area. This is the most efficient lighting, in terms of memory utilization, as the lighting is done once and for all.
6.2.5 Concept of Texture Mapping
Figure 6.2.5.1 A Texture File The figure above show an example of a texture file. A texture file will have the following characteristic: 1. File size will be very small, typically around 16X16 the least, and 256X256 the most. 2. Having a low and perhaps, moderate details. 3. Having many combinations of colors and produce valuable information to the source that uses it. 4. Symmetric at the x axis, y axis, 45 angle, and 135 angles. 5. Must form a continuous image when combine together. David War Game uses the texture mapping concept for its object representation. Before a texture can be loaded into the system and applied to the specific object, it needs to be declared in a MTL file first. A MTL file stores a set of images and textures definition for the system. This is done in order to make the system more organize. A texture file must also be the size of 2n , as the information stores in a texture file is in binary form, and of the form 2n, . Besides that, a texture file must also have 256 bit color information, and a depth of 72 colors per pixel. This setup was standardized in David War Game and must be strictly followed by the Game Programmers. A texture must also be declared in the Object File. The command for this declaration is usemtl sometexturefilename. Before that, the call to link the MTL file must be invoked at the beginning of the OBJ file. When a texture is loaded into the system, it will be mapped onto the objects. There will be an algorithm to fit the texture file exactly into the object. The information below shows an example of texture declaration:
David War Game Final Report Final Year Project 2004/05 # load materials, link to the MTL file mtllib textures.mtl # define vertices v 16 32 16 v 16 32 -16 v 16 0 16 v 16 0 -16 v -16 32 16 v -16 32 -16 v -16 0 16 v -16 0 -16 g myCube #use the texture file name GR usemtl GR f1342 f6875 f2651 f3784 f1573 f4862
Texture Mapping
Figure 6.2.5.2 Texture Mapping Examples 127 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
6.3 Objects in 3D
6.3.1 Definition of an Object
For the 3D Game, there will be tanks, soldiers and crates as well. These units and weapons can be called as objects. Objects need to be created in the game and need to be different from other objects as well. An object in David War Game can be classified under the following aspect: 1. A class that extends GameObject abstract class. 2. A non static element in the game by definition. (Although it can be static as well). 3. An element that can feel, touch and interact with other objects. 4. An element that is constructed from a set of polygons. 5. An element which has application of texture mapping. 6. An element that is updated all the time. 7. An element of important task in the system.
6.3.2 Format for OBJ file

To enhance the performance of the system, the system will load an object from an external file. This file will be given the extension OBJ. Of course, before an object is created, the object needs to be coded in the OBJ file first before it was loaded into the system. The system also needs a parser to parse this file and make it into an understandable format. No doubt that this programming concept not only made the system more efficient (in terms of no repetitive call to made an object), it makes the system slower due to its loading time from an external file. To make a valid OBJ file, a format need to be created in order to be parsed by the parser. Thus, a standardized format needs to be implemented for the OBJ file. Not only that the programmers needed to conform to this specified format, but the Plug In developer must also conform to this format as well. The format defined for the OBJ file will be based on the one developed by David Brackeen. (visit www.brackeen.com/javagamebook)
David War Game Final Report Final Year Project 2004/05 Format for the OBJ file: # OBJ - Wavefront object file # The javagamebook loader only understands these commands: # mtllib <filename> - Load materials from an external .mtl # file. # v <x> <y> <z> - Define a vertex with floating-point # coords (x,y,z). # f <v1> <v2> <v3> ... - Define a new face. a face is a flat, # convex polygon with vertices in # counter-clockwise order. Positive # numbers indicate the index of the # vertex that is defined in the file. # Negative numbers indicate the vertex # defined relative to last vertex read. # For example, 1 indicates the first # vertex in the file, -1 means the last # vertex read, and -2 is the vertex # before that. # g <name> - Define a new group by name. The faces # following are added to this group. # usemtl <name> - Use the named material (loaded from a # .mtl file) for the faces in this group.
6.3.3 GameObject class

The GameObject class must be extended by all class that wishes to be defined as an object in David War Game. It has some methods and variables predefined in it, which may be overridden by the subclass, if necessary, depending on the individual needs. The GameObject abstract class is as follows: //taken from www.brackeen.com/javagamebook package com.brackeen.javagamebook.game; import java.util.*; import com.brackeen.javagamebook.math3D.*; import com.brackeen.javagamebook.scripting.*; public class GameObject { public static final int STATE_IDLE = 0; public static final int STATE_ACTIVE = 1; public static final int STATE_DESTROYED = 2; 129 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
private PolygonGroup polygonGroup; private PolygonGroup polygonTurret; private PolygonGroupBounds bounds; private PolygonGroupBounds boundsT; private int state; private int stateT; private boolean isJumping; private boolean isFlying; private float floorHeight; private float ceilHeight; private long noiseDuration; private List spawns; private List touching; private List touchingThisFrame; private GameObjectEventListener listener; public GameObject(PolygonGroup polygonGroup,PolygonGroup turret) { } public GameObject(PolygonGroup polygonGroup) { } public Vector3D getLocation() { } public Vector3D getLocationT() { } public MovingTransform3D getTransform() { } public MovingTransform3D getTransformT() { } public PolygonGroup getPolygonGroup() { } public PolygonGroup getPolygonTurret() { } public String getName() { } public String getNameT() { 130 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 } public PolygonGroupBounds getBounds() { } public PolygonGroupBounds getBoundsT() { } public float getX() { } public float getY() { } public float getZ() { } public float getXT() { } public float getYT() { } public float getZT() { } public void setFloorHeight(float floorHeight) { } public void setCeilHeight(float ceilHeight) { } public float getFloorHeight() { } public float getCeilHeight() { } public void setState(int state) { } public void setStateT(int stateT) { } protected void setState(GameObject object, int state) { 131 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 } public void setStateT(GameObject object, int stateT) { } public boolean isFlying() { } public void setFlying(boolean isFlying) { } public boolean isJumping() { } public void setJumping(boolean b) { } public boolean isIdle() { } public boolean isActive() { } public boolean isDestroyed() { } public boolean isMakingNoise() { } public void makeNoise(long duration) { } protected void addSpawn(GameObject object) { } public List getSpawns() { } public void update(GameObject player, long elapsedTime) { } public GameObjectEventListener getListener() { } 132 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
public void addListener(GameObjectEventListener l) { } public void removeListener(GameObjectEventListener l) { } protected void notifyVisible(boolean visible) { } protected void notifyObjectCollision(GameObject otherObject) { } protected void notifyObjectTouch(GameObject otherObject) { } protected void notifyObjectRelease(GameObject otherObject) { } protected void notifyFloorCollision() { } protected void notifyCeilingCollision() { } protected void notifyWallCollision() { } public void sendTouchNotifications() { } }
6.3.4 Animation
When an object is constructed, it must be able to perform transformation. In other words, the object must be able to change shape from a form to another form. Therefore, an object class needs an update and draw method. The update method will update all the variables and states of an object. The draw method, on the other hand, will draw the newly formed object. These update and draw methods will be called every 30 miliseconds on the average, depending on the type of object. (A crate box will be updated every 1 second because it is static, while a player will be updated every 10 miliseconds, as the player plays the primary role in the system.) The object class will called the update method, followed by the draw method, and this order must be strictly followed! There are many types of transformation being applied to an object. (Refer to the 3D Graphics Basic for more information). A few common transformations would be the translation and rotation. These transformations need to be applied in order for the object to have an animation. However, transformation will be applied based on the current condition of the object. For example, when an enemy object tries to run away, the enemy object will have a rotation to turn to the opposite site, then a translation to move to some distance away, and finally a scale so that it will shrink in size as it goes further. A static stair, on the other hand, will only have scale being applied to adjust the size as the player moves toward it. (This transformation will be applied in the update method, and the subsequent draw method will draw the resulting images based on the value given by the update method). Because the object is refresh every 30 miliseconds, the user will experience some animation effect on the object as the system runs. However, the memory allocation needs to be large as a low memory and execution speed will result in the screen producing some flickers.
6.3.5 Polygon Group Concept

To construct an object, the system needs a predefined rule to make an object. This rule, using the polygon group concept, will create the object from a low level perspective. During the Initial Phase of the Project, some questions arise whether the David War Game Object Creation Feature is able to create a curve object or not. An issue has also been raised up on the possibility of creating meshes for the object. For David War Game, it was agreed that the Object Creation need to be standardized. Therefore, the system will use polygon group concept for its object creation capability. The details of Polygon Group Concept are as follows: 1. First, the vertices and coordinates for the object will be assigned and defined. 2. For every 3 or more vertices, these vertices will be combined to form a polygon structure. (A triangle, rectangle, or others) 3. If possible, the polygon will be combined to form a block. (For example, a Cube). 4. This block is known as polygon group. 5. A collection of multiple polygon groups will form the object. 6. For a simple object, such as a crate box, the implementation effort will be minimal. (Maximum 16 polygons, minimum 8 polygons). 7. For a very detail object, such as a Tank, the implementation effort will be tedious. (Maximum 900 polygons, minimum 60 polygons). 8. Refer to the figure below for an overview of the object construction and creation. Object Construction:
Figure 6.3.5.1 Two vertices defined
Figure 6.3.5.2 A line was formed
Figure 6.3.5.3 A Polygon
Figure 6.3.5.4 Multiple Polygon, forming polygon group
Figure 6.3.5.5 Multiple polygon group, forming an object (Simple house)
6.3.6 Parser for OBJ file

David War Game needs a parser to parse the OBJ file for an object. When an object has been coded in the OBJ file extension format, the system must parse the file first before it could load the object into the system. Only when the file is being declared as valid that the object can be created. The parser (ObjectLoader class) for the Object File is as follows: //taken from www.brackeen.com/javagamebook public class ObjectLoader implements Serializable { int line1=0; public boolean notvalid=false; public static class Material { public File sourceFile; public ShadedTexture texture; } protected interface LineParser { public void parseLine(String line) throws IOException, NumberFormatException, NoSuchElementException; public void parseLinePlug(String line) throws IOException, NumberFormatException, NoSuchElementException; } protected File path; protected List vertices; protected Material currentMaterial; protected HashMap materials; protected List lights; 137 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 protected float ambientLightIntensity; protected HashMap parsers; private PolygonGroup object; private PolygonGroup currentGroup; String colorType1=""; public ObjectLoader() { } public void setLights(List lights, float ambientLightIntensity) { }
public PolygonGroup loadObject(String filename) throws IOException { } public PolygonGroup loadObject(String filename,String colorType) throws IOException { } protected Vector3D getVector(String indexStr) { } protected void parseFile(String filename) throws IOException { } protected void parseFilePlug(String filename) throws IOException { } protected class ObjLineParser implements LineParser { public void parseLine(String line) throws IOException, NumberFormatException, NoSuchElementException 138 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 { } public void parseLinePlug(String line) throws IOException, NumberFormatException, NoSuchElementException { } } protected class MtlLineParser implements LineParser { public void parseLine(String line) throws NoSuchElementException { } public void parseLinePlug(String line) throws IOException, NumberFormatException, NoSuchElementException { } } } Based on the standardized format specified in David War Game, the parser would be checking for the following command: 1. mtllib [filename] This command will instruct the system to load the necessary MTL Library file. It will be used later in the system for texture mapping. 2. v [x] [y] [z] The v syntax enables the system to construct a vertices based on the point given by x, y, and z coordinates. 3. f [v1] [v2] [v3] The f syntax enables a polygon group to be defined and created from a set of vertices. 4. g [name] The g command will let the system to apply some color to the object being created. (Can also used the texture file, if necessary) 5. usemtl [name] This command enables the system to use the texture that is defined by the MTL Library file. If the MTL Library file does not define the texture, then the parser will report an error. 139 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
6.3.7 Objects in David War Game

Overview David War Game will have many objects in its system. These objects can be differentiated into two parts, static and non-static object. A static object will not consume the computers memory too much, as its update method will only be called every 1 second, while a non-static object took the systems memory in great amount. In order to compensate between the level of details and memory consumption, Objects in David War Game were designed at a reasonably low detail level, as it was agreed that the memory consumption and efficiency are a more important factor for the efficient running time of the system.
6.3.7.1
6.3.7.1.1
Normal Objects
Crate Boxes
A crate box will have 8 polygons by default. It existence in the system is to enhance and made the game more realistic. However, it does not serve any important role for the player and enemy units (Such as increasing the players life). It might also serve to give an obstacle to the player or as a protective shield when the enemy units fire at the player. Figure below gives the texture for a crate box.
Figure 6.3.7.1.1 Crate Box 6.3.7.1.2 Health Boxes
A health box has a same design as the crate box. Unlike the crate box which serves no purposes to the player, a health box increases the life of a player by 20 when the player touches it. A health box can also serves as a protective shield for the player. However, it cannot act as an obstacle for the player, as it will be destroyed upon touching, but it can act as an obstacle for the enemy units. The Health Box will be destroyed upon touching under every conditions, even if the player life is full, it will be destroyed, and update the player life to the same value.(Full life, 100%). Figure below gives the texture for the health box.
Figure 6.3.7.1.2 Health Box 140 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 6.3.7.1.3 Ammo Boxes
Like the crate and health boxes, the ammo box has the same design as the other two. Ammo box gives additional ammo for the player. It is weapon specific by nature. (A Ammo Box for the Heavy Machine Gun will only increase the ammo for the Heavy Machine Gun, not others like Hand Gun). The ammo box will also be destroyed under every condition when touched, just like the health box. Ammo is also known as Ammunition, in a more specific term. There are 9 different ammo boxes, and each of them is weapon specific. The list below shows all of them: 1. 2. 3. 4. 5. 6. 7. 8. 9. Hand Gun Ammo Box Rifle Ammo Box Sub Machine Gun Ammo Box Machine Gun Ammo Box Heavy Machine Gun Ammo Box Mine Ammo Box Time Bomb Ammo Box Sand Grenade Ammo Box Bazooka Ammo Box
The figure below shows the texture of an ammo box (Hand Gun Ammo Box).
Figure 6.3.7.1.3 Hand Gun Ammo Box
6.3.7.2
Enemy Objects
For the enemy units, the German will have the official German Grey and the North Afrika Yellow Scheme as its color scheme. The US will have dark brown as its official color while the Russian will have jungle green camouflage as its color scheme. 6.3.7.2.1 Tiger I Heavy Tank
Figure 6.3.7.2.1 Tiger I Tank The Tiger I Heavy Tank Capability: Speed Armor Firepower AI Braveness Visibility : *** Size : ***** : : : : : **** ***** ***** **** *****
Tiger I Tank comes in two color schemes, the official German Grey and the North Afrika Yellow Scheme. Tiger I Tank can be known as the most potent mechanized unit in David War Game. Based on the characteristic above, a Tiger I Tank is a tank with great firepower, huge armor, good speed and smart as well. It is hard to be destroyed by just a few shot. Moreover, it is brave towards any enemy units (The pattern has been set to Aggressive under all conditions). It is big in size, due to the fact that it is a Heavy Tank. Tiger I Tank cannot be destroyed by any infantry weapons (Hand Gun, Rifle, Sub Machine Gun, Machine Gun, and Heavy Machine Gun). It requires a few shot by Anti Tank Weapons in order to destroy it. (3 charges of time bomb on average, 12 rounds of bazooka ammo, 3 anti tank mines, 6 sand grenades that hit it directly, or 9 sand grenades that hit on its surrounding). No doubt that Tiger I Tank perform well on the average, it still lack of visibility in general. 142 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 6.3.7.2.2 JagdPanther Tank Destroyer
Figure 6.3.7.2.2 JagdPanther Tank Destroyer The JagdPanther Tank Destroyer Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: *** ***** ***** ** ***** ** *****
The JagdPanther Tank is a subversion of the Tiger I Tank. It has limited visibility compared to the Tiger I (Due to the fact that it does not have a turret). It is also slower than the Tiger I Tank. (Because it is heavier and more equipped). However, it is very dump and performs badly during battle. (The AI Unit has been set to 2/5 for Intelligence Unit). Like the Tiger I Tank, it is heavily armored and bold (Pattern has been set to Aggressive under all conditions, and life has been set to 800, the same as the Tiger I Tanks). The JagdPanther Tank requires 3 charges of time bomb on average, 12 rounds of bazooka ammo, 3 anti tank mines, 6 sand grenades that hit it directly, or 9 sand grenades that hit on its surrounding in order to destroy it. (The same as the Tiger I Tank).
David War Game Final Report Final Year Project 2004/05 6.3.7.2.3 Half Track
Figure 6.3.7.2.3 Half Track The Half Track Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: ***** *** *** **** *** **** ***
Half Track can be known as the most coward enemy unit in David War Game. Its pattern has been set to Aggressive under battle condition, StayPut under hold condition and RunAway under reloading condition. It also suffers from low armor, which expose it to heavy infantry weapon as well as deadly anti tank weapons. However, it is small in size and has a remarkable speed. It requires 1 charges of time bomb on average, 2-3 rounds of bazooka ammo, 2 anti tank mines, 2-3 sand grenades that hit it directly, or 3-4 sand grenades that hit on its surrounding in order to destroy it.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.4 88 Anti Tank Gun
Figure 6.3.7.2.4 88 Anti Tank Gun The 88 Anti Tank Gun Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: * *** ***** ** ***** *** **
The 88 Anti Tank Gun serves as a defensive weapon against the enemy. It has great firepower, and is bold enough to face the enemy. However, it cannot move, making it vulnerable to attack from all angles. Armor was low as well, which make it easily to be destroyed by a standard Anti Tank Weapon. (1 charges of time bomb on average, 2 rounds of bazooka ammo, 2 sand grenades that hit it directly, or 3 sand grenades that hit on its surrounding in order to destroy it, note that Anti Tank Mines cannot destroyed it as the 88 cannot move at all).
David War Game Final Report Final Year Project 2004/05 6.3.7.2.5 Sherman Medium Tank
Figure 6.3.7.2.5 Sherman Tank The Sherman Medium Tank Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: **** **** **** **** **** **** ****
The Sherman Medium Tank serves as a well rounded tank in David War Game. Its capability is to compensate for the speed and firepower, while being able to perform all the tasks that are required at the same time. It requires 2 charges of time bomb on average, 6 rounds of bazooka ammo, 2 anti tank mines, 4 sand grenades that hit it directly, or 6 sand grenades that hit on its surrounding in order to destroy it.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.6 T34 Medium Tank
Figure 6.3.7.2.6 T34 Tank The T34 Medium Tank Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: **** **** **** **** **** **** ****
Like the Sherman Medium Tank, the T34 Medium Tank serves as a well rounded tank in David War Game as well. Its capability is to compensate for the speed and firepower, while being able to perform all the tasks that are required at the same time. It requires 2 charges of time bomb on average, 6 rounds of bazooka ammo, 2 anti tank mines, 4 sand grenades that hit it directly, or 6 sand grenades that hit on its surrounding in order to destroy it.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.7 Infantry Unit
Figure 6.3.7.2.7 Infantry Unit
The Infantry Unit Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: **** ** ** ***** *** ***** **
Infantry Unit will be a smart enemy unit. However, it has shorter lifespan and low armor at the same time. Not only that, it cannot easily kills the player. Infantry Unit can be easily destroyed by Anti Tank Weapon and the Infantry Weapon could also be a potent weapon to destroy it as well. (Especially the Heavy Machine Gun).
David War Game Final Report Final Year Project 2004/05 6.3.7.2.8 Bazooka Team
Figure 6.3.7.2.8 Bazooka Team The Bazooka Team Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: **** ** *** ***** *** ***** **
Like the Infantry Unit, the Bazooka Team has shorter lifespan and low armor as well. However, it was designed to be a smart enemy unit. It also has better weapon than the Infantry Unit, which gives it more firepower. It can be easily destroyed by any enemy weapon, just like the Infantry Unit.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.9 Bunker
Figure 6.3.7.2.9 Bunker The Bunker Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: * ***** ***** ** ***** *** *****
Bunker is stupid and slow to respond to action. (That is why it has poor speed, AI and Visibility). However, Bunker is very durable and not easily destroyed by the enemy. It is also bold when take into action, due to its long life span and high armor. For a bunker to be destroyed, it took 5 charges of time bomb on average, 18 rounds of bazooka ammo, 15 sand grenades that hit it directly, or 20 sand grenades that hit on its surrounding in order to destroy it. However, this extra hard capability has been compensated by giving the bunker a poorer AI and slow respond rate.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.10 Z Tekken
Figure 6.3.7.2.10 Z Tekken
The Z Tekken Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: ***** ***** ***** ***** ***** ***** *
Z Tekken serves as the God Unit in David War Game. It has all the powerful capability of all the enemy units in David War Game. Therefore, it will make the player task more difficult when he encounters this enemy unit. Like the Bunker, it took 5 charges of time bomb on average, 18 rounds of bazooka ammo, 15 sand grenades that hit it directly, or 20 sand grenades that hit on its surrounding in order to destroy it.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.11 Sturm Tiger
Figure 6.3.7.2.11 Sturm Tiger The Sturm Tiger Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: *** ***** ***** **** ***** *** *****
The Sturm Tiger Tank serves as an assault mortar tank. It has great armor, firepower and big in size. However, it is quite slow in speed and response time. It took 2 charges of time bombs, 4 sand grenades that hit it directly, 6 on the side, 3 mines and 7 rounds of bazooka to destroy it.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.12 Panther
Figure 6.3.7.2.12 Panther The Panther Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: **** **** **** ***** ***** **** ****
The Panther tank serves as an enhanced well rounded tank. It is more superior to the Sherman and T34, but less superior to the Tiger I tank. It took 2 charges of time bomb, 4 sand grenades, 2 mines and 5 rounds of bazooka to destroy it.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.13 JS2
Figure 6.3.7.2.13 JS2 The JS2 Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: **** ***** ***** ***** ***** **** *****
JS2 serves as a heavy tank to the Soviet Union army. It has the capability that matches the German Tiger I Tank. In fact, it is more superior to the Tiger I tank in some aspect. To destroy this tank, it took 3 charges of time bomb, 6 sand grenades, 4 mines and 8 round of bazooka ammo.
David War Game Final Report Final Year Project 2004/05 6.3.7.2.14 Willy
Figure 6.3.7.2.14 Willy The Willy Capability: Speed: Armor: Firepower: AI: Braveness: Visibility: Size: ***** ** ** ***** *** **** ***
Willy is a small vehicle and only carries a small machine gun. It has more armor compared to the infantry, but it is vulnerable to infantry weapons as well. Willy is easy to destroy than other vehicles, with just a few shot of infantry weapons, and one round of any anti tank guns.
6.3.7.3
Player
The Player in David War Game will be the hero in the system. Whenever a game starts, the player will be equipped with 150 rounds of Hand Gun Ammo, 80 rounds of Rifle Ammo, 150 rounds of Sub Machine Gun Ammo, 150 rounds of Machine Gun Ammo, 250 rounds of Heavy Machine Gun Ammo, 100 rounds of Bazooka Ammo,15 Anti Tank Mine, 20 Sand Grenade, and 15 units of Time Bomb. When the player wants to reload a weapon, it usually takes about 5 seconds to do this. A player can jump, walk, strafe and turn in the 3D Environment. To make the status of the player more obvious, a health bar and player face has been created in the Player Panel, located under the left corner of the screen. (See figure below for more details).
Player Panel
Figure 6.3.7.3 Player Panel
6.4 Map For The Environment in 3D Game

Overview: This chapter will give an overview on the basis of how to create a 3D Environment. It is a very long and complicated process to create a 3D Environment, so this chapter will be dedicated only to provide the fundamental aspect of the 3D Environment.
6.4.1 Binary tree basis

To construct a 3D Environment, it is important that the 3D Environment to be created in stages and modularized as much as possible. Therefore one possible way to implement this is to separate the 3D Environment into separate units, called rooms. The system can made each room as a node in a tree. In other words, the system can construct a binary tree that consists of collection of nodes where each node represents a room. Refer to the figure below for more details:
Figure 6.4.1.1 A binary tree Definition of Binary Tree: A binary tree has a root, which supports the child node and is the ancestor node for every child node. A parent node can have one or more child node. A parent node that has no child node is called a leaf. There are many types of searches that operate on a tree, such as the Binary Searches, Pre Order Search, and Post Order Search. A parent node cannot have more than two children.
David War Game Final Report Final Year Project 2004/05 Extension to Multiway Tree: It can be seen that the Binary Tree has its disadvantages. The most obvious one will be the incapability to support many child nodes. Therefore, an implementation needs to be made on a way to create a tree that supports many child nodes. This new tree, of course, will be named as multiway tree. (Some referred to them as B-Tree). (See figure on the multiway tree).
Figure 6.4.1.2 A multiway tree
6.4.2 Painters algorithm

There are several concepts available in drawing a 3D Environment. The most obvious and simplest way, of course will be the Painters Algorithm. A Painters Algorithm will paint the 3D Environment based on the position. If object A is further than object B, then object A will be painted first. Before that, the screen needs to be painted first with an initial color. (For David War Game, this color will be blue). However, it is an obvious fact that the Painter Algorithm consumes too much memory as it needs to paint the entire screen. Moreover, it spends too much time painting over part of a screen multiple times. Therefore, a more efficient method needs to be applied to replace the Painters Algorithm.
6.4.3 1D and 2D BSP Tree

A BSP Tree is known as the Binary Space Partition Tree. It comes in three forms, the 1D, 2D and 3D form. It has been a proven method that using BSP Tree will be an efficient method in creating a 3D Environment. A 1D BSP Tree will be of course a collection of coordinates. (See figure 6.4.3.1). 2D BSP Tree will be a set of 2D Environment, where there are a collection of lines. David War Game needs 2D BSP Tree for its 3D Environment. The concepts below explain how the BSP Tree might solve the memory problem in the 3D Environment.
Figure 6.4.3.1 A 1D BSP Tree
Figure 6.4.3.2 A 2D BSP Tree
David War Game Final Report Final Year Project 2004/05 Concept of 2D BSP Tree: 1. First the system will read the line AB. It will paint the region AB. See figure 8.1.3.3. 2. Then the system will read line BC. It will paint only the region as shown in figure 8.1.3.4. This saves the extra space of the shaded area (yellow). 3. The system paints the region given by line ED. (Figure 8.1.3.5). 4. Finally, the system finishes the painting by painting based on the line EF. (Figure 8.1.3.6). 5. As can be seen from all the figures, it is obvious that the system will not redraw the area that is intercepted between two lines. The author of this report would like to apologize if the explanation given is not really clear as explaining the whole process in a 3D Environment is a tedious and time consuming task.
Figure 6.4.3.3 Step 1
6.4.4 Plane (3D) BSP Tree

An extension could be made on the BSP Tree to support 3D BSP Tree. 3D BSP Tree would separate a 3D Environment instead, and this is done by plane partitioning. (Unlike the 2D BSP Tree which does the line partitioning). Explanation on the 3D BSP Tree will not be given based on the two reasons: 1. It is hard and tedious to explain this concept. 2. There is little implementation of 3D BSP Tree in David War Game.
6.4.5 MAP file format

To create a 3D Environment, it is inadvisable to create it in the system by itself. Therefore, like the object creation, a standardized format need to be given on the map creation. This map format will be stored in a file with extension map. The format is as follows: (For more information, visit www.brackeen.com/javagamebook) # MAP - backart2 map format. # # v [x] [y] [z] - Define a vertex with floating-point # coords (x,y,z). # mtllib [filename] - Load materials from an external .mtl # file. # usemtl [name] - Use the named material (loaded from a # .mtl file) for the next floor, ceiling, # or wall. # ambientLightIntensity # [value] - Defines the ambient light intensity # for the next room, from 0 to 1. # pointlight [v] - Defines a point light located at the # [intensity] specfied vector. Optionally, light # [falloff] intesity and falloff distance can # be specified. # player [v] [angle] - Specifies the starting location of the # player and optionally a starting # angle, in radians, around the y-axis. # obj [uniqueName] - Defines an object from an external # [filename] [v] OBJ file. The unique name allows this # [angle] object to be uniquely identfied, but # can be "null" if no unique name is # needed. The filename is an external # OBJ file. Optionally, the starting # angle, in radians, around the y-axis # can be specified. # room [name] - Defines a new room, optionally giving # the room a name. A room consists of # vertical walls, a horizontal floor # and a horizontal ceiling. Concave rooms # are currently not supported, but can be # simulated by adjacent convex rooms. # floor [height] - Defines the height of the floor of # the current room, using the current # material. The current material can # be null, in which case no floor # polygon is created. The floor can be 162 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 # # # # # # # # # # # # # # # # # # # above the ceiling, in which case a "pillar" or "block" structure is created, rather than a "room". ceil [height] - Defines the height of the ceiling of the current room, using the current material. The current material can be null, in which case no ceiling polygon is created. The ceiling can be below the floor, in which case a "pillar" or "block" structure is created, rather than a "room". wall [x] [z] - Defines a wall vertex in a room using [bottom] [top] the specified x and z coordinates. Walls should be defined in clockwise order. If "bottom" and "top" is not defined, the floor and ceiling height are used. If the current material is null, or bottom is equal to top, no wall polygon is created.
6.4.6 Map Loader/Parser

To make the map file into an understandable form, a parser is needed to organize this file into a specific form. This parser will extend from the object parser class. It will perform many more functionalities compared to the object parser. The Map Loader and Parser are as follows: //taken from www.brackeen.com/javagamebook package com.brackeen.javagamebook.bsp2D; import java.io.*; import java.util.*; import com.brackeen.javagamebook.math3D.*; import com.brackeen.javagamebook.game.*; public class MapLoader extends ObjectLoader implements Serializable { private BSPTreeBuilder builder; private Map loadedObjects; private Transform3D playerStart; private RoomDef currentRoom; private List rooms; private List mapObjects; private ObjectLoader objectLoader; 163 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 public MapLoader() { } public MapLoader(BSPTreeBuilder builder) { } public BSPTree loadMap(String filename) throws IOException { } public BSPTree loadMapPlug(String filename) throws IOException { } protected BSPTree createBSPTree() { }
public List getObjectsInMap() { } public Transform3D getPlayerStartLocation() { } public void setObjectLights(List lights, float ambientLightIntensity) { } public List getRooms(){ } protected class MapLineParser implements LineParser { public void parseLine(String line) throws IOException, NoSuchElementException { 164 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 } public void parseLinePlug(String line) throws IOException, NoSuchElementException { } } }
6.4.7 Front to Back Principles

The easiest way to refresh and repaint a screen is to apply the front to back principle. A front to back principle is based on the farthest object being painted first, followed by the second farthest, and so on. (Refer to figure 6.4.7 for more details). The figure shows that D is painted first, followed by A, then B and finally C. D is the farthest object, followed by A, then B, and finally C.
Figure 6.4.7 Front to Back Principle
6.4.8 2D Map Display of the Environment

One of the interesting features in David War Game is the ability to know the map of the 3D Environment in 2D form. It is one of the hardest parts of implementation in terms of design effort. This 2D Map Display serves as a distinguished feature compared to other First Person Shooter 3D Game Concept. The 2D Map Display uses the concept of wall and its vertices to display the map in 2D form. It is available in two forms, the 1024X768 resolution and 800X600 resolutions. The map, however, need to be displayed in a inverse form as the 3D Environment coordinates is the mirror of the 2D Map Display coordinates. Only the X and Z axes is needed for the 2D Map Display, as the Y axis is used only for the height. The 2D Map Display is also capable of displaying the enemy objects as well as the player and the static objects. Moreover, it can also display the enemy shells and bullets. (This includes the player weapons and shells). Figure below shows the 2D Map Display:
The vertices and edges in a map
Figure 6.4.8 The 2D Map Display
6.5 Unit Editor

Overview: As has been proposed initially, David War Game will have features that are not available in the market at the moment. This feature must be new and attractive to the game users. One of those distinguished features that David War Game will have is the Unit Editor. So far, there is no available First Person Shooter Concept War Games that has a Unit Editor implemented in it. David War Game is proud to have this feature as part of its system. A Unit Editor enables the user to create his own enemy units based on his own criteria and choices.
6.5.1 Enhanced Parser

The Unit Editor in David War Game will have an enhanced parser implemented as part of its features. This is done by adding an additional code into the existing parser, the object parser. This new parser must have the capability to differentiate the country of origin of the enemy unit, the enemy units object parts (separated by the polygon groups), and the enemy position in the Unit Editor Menu. The code fragment below shows the changes made to the object parser in order for the Unit Editor to be made possible: else if (command.equals("usemtl")) { // define the current material String name = tokenizer.nextToken(); if(colorType1.equals("Germany")&&!name.equals("black")){ currentMaterial = (Material)materials.get("texture_G"); } if(colorType1.equals("US")&&!name.equals("black")){ currentMaterial = (Material)materials.get("UC");//"dyellow"); } if(colorType1.equals("Soviet")&&!name.equals("black")){ currentMaterial = (Material)materials.get("RC");//"dgreen"); } if(colorType1.equals("")||name.equals("black")){ currentMaterial = (Material)materials.get(name); } if(colorType1.equals("Germany")&&(name.equals("Soviet")||name.equals("Allies")) ){ currentMaterial = (Material)materials.get("Nazi"); } if(colorType1.equals("Germany")&&(name.equals("Nazi"))){ 167 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 currentMaterial = (Material)materials.get("Nazi"); } if(colorType1.equals("US")&&(name.equals("Nazi")||name.equals("Soviet"))){ currentMaterial = (Material)materials.get("Allies"); } if(colorType1.equals("US")&&(name.equals("Allies"))){ currentMaterial = (Material)materials.get("Allies"); } if(colorType1.equals("Soviet")&&(name.equals("Nazi")||name.equals("Allies"))){ currentMaterial = (Material)materials.get("Soviet"); } if(colorType1.equals("Soviet")&&(name.equals("Soviet"))){ currentMaterial = (Material)materials.get("Soviet"); } if (currentMaterial == null) { System.out.println("no material: " + name); } } It is noticeable that there are many conditional processing in the new parser. These are needed as part of the requirements for the Unit Editor to differentiate between enemy units parts such as Country of Origin.
6.5.2 Country, Head, and Body Features

For a normal 3D Game, the enemy object will be loaded as a whole object, regardless of its sub object. In the Unit Editor, the enemy unit will be loaded in three separate forms, which are Country of Origin, Head and Body. Only enemy objects having these three separate parts can be loaded into the Unit Editor. (Tiger I Tank can be loaded as it has Germany as its Country of Origin, Turret as its Head and Chassis as its Body, but 88 Anti Tank Gun cannot be loaded as it only has Germany and Chassis as its Country of Origin and Body.) The object that is being created in the Unit Editor will be combined from these three forms, which form the new enemy units. (See figure below for more details).
Head
Body Country
Figure 6.5.2 The Country, Head and Body Concept.
6.5.3 Reuse of OBJ file

For a more efficient implementation, the Unit Editor will reuse the format of the OBJ file as its object creation capability. This includes the reuse of the OBJ file extension as well. However, the OBJ file that contains these Unit Editor Object will have three separate forms, one for the Country of Origin, one for the Head and one for the Body instead of only one for the entire object. (For example, the Tiger I Tank OBJ file will be separated into 3 forms, The Tiger I Germany, The Tiger I Body, and The Tiger I Head).
Chapter 7 Artificial Intelligence, Interactivity and Path Finding Among Objects in 3D Game
7.1 Collision Detection
Overview: It is obvious that Collision Detection plays an important role in the 3D Environment. Collision Detection serves as a way of preventing two objects from mixing together. It also serves to prevent an object from running out of the 3D Environment Space.
7.1.1 Type of Collision Detection

Overview of type of collision detection: There are many types of collision detection. Some of the most common one are Box and Cylinder Collision Detection. Some of the collision detections are more efficient than others, while some are simpler than others in terms of implementation effort.
7.1.1.1
Box
The simplest and most efficient collision detection will be the box collision detection. Box collision detection will treat the object as a box. An object is considered to collide with other object only if the object boundary intercept with the other object boundary. (See figure below for the type of box collision detection).
Figure 7.1.1.1 Box Collision Detection 170 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
7.1.1.2
Cylinder
Cylinder type collision detection seems to be an improvement to the box type collision detection. Cylinder type collision detection provides more accurate collision detection than the box since it eliminates a lot of unnecessary space provided by the box. However, it is more complex and harder to implement. No doubt that it has this disadvantage, it stills become the preferred choice of many game programmers in implementing the collision detection. David War Game will use the cylinder type collision detection for its collision detection feature. Figure below gives how cylinder type collision detection looks like:
Figure 7.1.1.2 Cylinder Type Collision Detection
7.1.1.3
Rectangle
Rectangle type collision detection is in some way similar to the box type collision detection, except that it covers more space and area compared to the box type collision detection. Refer to the figure below for more detail:
Figure 7.1.1.3 Rectangle Type Collision Detection
7.1.1.4
Object detection
Object type collision detection is by far the most complicated and hardest to implement. It is also the most accurate type of collision detection compared to other type of collision detection. This is because the nature of this collision detection involves the exact area of the entire object for the collision detection facilities. Unlike others, it does not waste extra spaces for the collision detection. However, the area involved in the collision detection is non deterministic and uneven, making the implementation for this type of collision detection almost impossible. This method of implementation would not be preferred by many Game Programmers due to the extra large amount of effort required to implement it. In fact, it wastes a lot of unnecessary memory spaces for this implementation. This method is only used in the Engineering CAD Analysis, where the accuracy of information needs to be high.
7.1.2 Object and Object Collision

For the David War Game, when an object collides with another object, it will invoke the method notifyObjectCollision(Object other). Object other is the object that it is colliding with. This parameter is needed as the parent object will take the necessary steps to handle with this collided object. An object can also collide with the static object. Usually, nothing is done when the object collides with crate box, but an action needs to be invoked when an object collide with other static object, such as Health Box. (This action will be to increase the health of the object). Object and Object Collision needs to be performed all the time, typically every 10 miliseconds. In fact, it serves as an important part in the 3D Game. An object must also not be able to coincide with other object, as this might affect the realism and accuracy of the game. (A user will be frustrated if he sees two objects combine together and walking in the same direction at the same time).
7.1.3 Object and World Collision

Object and World Collision will involved the collision between an object with its surrounding environment, such as the wall, ceiling, and floor. This type of collision detection is needed so as to not let the object moves outside the environment space. The methods to deal with this type of collision detection will be the notifyFloorCollision(), notifyCeilingCollision(), and notifyWallCollision(). The system needs three different methods instead of one because the floor, wall and ceiling are of different type, therefore they need to be deal with differently from each other. (Although some object, such as the Projectile, treat these three things as being the same). Like the Object and Object Collision, the Object and World Collision will need to be updated all the time, typically every 10 miliseconds. 172 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
7.1.4 Enhanced Collision Detection (Sliding Principle)

There is a specific class that deals with the collision detection. This class will be known as the GridGameObjectManager. It is in this class that all the position of the objects is stored. It is also in this class that all the coordinates of the 3D Environment are stored. This class will be updated every 10 miliseconds, and every object collision will be notified. There exists better collision detection, known as the Collision Detection With Sliding Principle, where when the player collide with the wall or objects, the player will slide through the wall or objects instead of doing nothing and idle there. However, this type of collision detection is only available to the player, due to the complexity that it imposed on the system. Below is an example of the GridGameObjectManager class. //taken from www.brackeen.com/javagamebook package com.brackeen.javagamebook.game; import java.awt.Rectangle; import java.awt.Graphics2D; import java.util.*; import com.brackeen.javagamebook.math3D.*; public class GridGameObjectManager implements GameObjectManager { private static final int GRID_SIZE_BITS = 9; private static final int GRID_SIZE = 1 << GRID_SIZE_BITS; private static class Cell { } private Cell[] grid; private Rectangle mapBounds; private int gridWidth; private int gridHeight; private List allObjects; private List spawnedObjects; private GameObject player; private Vector3D oldLocation; private CollisionDetection collisionDetection; public GridGameObjectManager(Rectangle mapBounds, CollisionDetection collisionDetection) { 173 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 } private int convertMapXtoGridX(int x) { } private int convertMapYtoGridY(int y) { } public void markAllVisible() { } public void markVisible(Rectangle bounds) { } public Iterator iterator() { } public void add(GameObject object) { } public void remove(GameObject object) { } public void addPlayer(GameObject player) { } public GameObject getPlayer() { } private Cell getCell(GameObject object) { } private Cell getCell(int x, int y) { } 174 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 public void update(long elapsedTime) { } public boolean checkObjectCollision(GameObject object, Vector3D oldLocation) { }
public void draw(Graphics2D g, GameObjectRenderer r) { } public void drawT(Graphics2D g, GameObjectRenderer r) { } public List getGameObject(){ } public List getSpawnObject(){ } }
7.2 Path Finding

Overview: Path Finding involves the enemy searching for the player. In other words, the enemy units need to have access to the players location. This location will be dynamic and must be within the search space. (In the 3D Environment).
7.2.1 Breadth first search

The easiest and simplest way of implementing a search that guaranteed an optimum path will definitely be the Breadth First Search. Besides that, the Breadth First Search does not need any extensive implementation effort to deal with. However, Breadth First Search suffers from memory and speed requirements. Not only that it takes more memory than any other more efficient searches, it takes more time to compute the search than any other searches. Therefore, a more efficient search needs to be implemented in order to deal with this problem.
7.2.2 Portals
There is a problem with implementing a tree for the searches. Question arises as how a node in a tree should be represented. The programmers need to sort out a way to make the objects recognized the path, and associate it into the tree. Therefore, every tree in the node will be representing some valuable information in the 3D Environment. One way to solve this problem is through the use of portal. A Portal is an empty wall in a specific room. It serves either as an entry or an exit for the room. A room might have one or more portal in it. See figure below for more information. Every time the map is loaded and constructed, if the parser encounters null for a wall creation, then the parser will create a portal for sure as the null wall will be an empty wall in the loaded map.
Figure 7.2.2 A Portal 176 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
7.2.3 A* Heuristic
If the system has portal for the empty walls, then the programmers can construct an A* Heuristic for the system. This A* Heuristic algorithm, will be optimal and search based on the portal given. Below are the description on the A* Heuristic Algorithm. (Note that the A* Heuristic Algorithm will construct the tree based on the players position.)
Figure 7.2.3.1 The A* Heuristic Algorithm The Tree For the A* Heuristic:
Figure 7.2.3.2 The Tree Diagram
David War Game Final Report Final Year Project 2004/05 1. 2. 3. 4. First, the enemy position, E will be the root node. Then, it branches out to three sub nodes, represented as the red line in the map. Each of the red node branches out to give one child node, labeled as blue. One of the blue child nodes is the leaf, and therefore does not expand any further. (Because it meets a dead end). 5. The other child nodes will expand further to give the purple nodes. 6. The purple nodes will expand to give brown nodes, and the brown nodes will finally give the green nodes. 7. Once the green nodes are created, it finds that the player is on that node as well (Portal). Therefore, the goal is met and the search stops at this point. The optimality of A* Heuristic The search algorithm for A* Heuristic is based on the equation A(n)=B(n)+C(n); Where n refers to that particular node, A is the total distance, B is the current distance, and C is the optimal distance. B is initializes to 0 at the beginning. C will be the distance between any two portals at that given node. It is for sure that the A* Heuristic is optimal given that the value C is the shortest distance between any two portals, and this C value does not overestimate the map value. (Refer to the figure given below for more details).
Figure 7.2.3.3 The optimality of A* Heuristic
7.2.4 Path Bot

For every enemy objects in David War Game, it needs a predefined information on the player locations. It must also have the capability to deduce and judge what actions are to be taken next. Therefore, a PathBot class is created to handle this task. The structure of the PathBot class is as follows: package com.brackeen.javagamebook.path; import javax.swing.*; import javax.sound.midi.Sequence; import javax.sound.midi.Sequencer; import javax.sound.sampled.AudioFormat; import java.io.*; import java.util.Iterator; import com.brackeen.javagamebook.path.PathFinder; import com.brackeen.javagamebook.math3D.*; import com.brackeen.javagamebook.game.GameObject; import com.brackeen.javagamebook.sound.*; import com.brackeen.javagamebook.ai.*; import com.brackeen.javagamebook.util.MoreMath; import javazoom.jl.decoder.*; import javazoom.jl.player.advanced.*; public class PathBot extends GameObject implements Serializable{ public static final float DEFAULT_TURN_SPEED = .005f; public static final float DEFAULT_SPEED = .25f; public static final long DEFAULT_PATH_RECALC_TIME = 4000; public static final float DEFAULT_FLY_HEIGHT = 64; private static final AudioFormat PLAYBACK_FORMAT = new AudioFormat(44100, 16, 1, true, false); protected PathFinder pathFinder; protected Iterator currentPath; protected Vector3D nextPathLocation; protected long timeUntilPathRecalc; protected long pathRecalcTime; protected Vector3D facing;
David War Game Final Report Final Year Project 2004/05 protected float turnSpeed; protected float speed; protected float flyHeight; protected float flyHeightT; public boolean isOne=false; public boolean canfire=true; public boolean isTank=false; public static boolean dontPlay1=false; public static SoundManager soundManager; public Sound trackSound; public Sound fireSound; public Sound destroySound; public static jlap2 playu1=new jlap2(); public PathBot(){ } public PathBot(PolygonGroup polygonGroup,PolygonGroup turret) { } public void setPathFinder(PathFinder pathFinder) { } public void setPathRecalcTime(long pathRecalcTime) { } public void setSpeed(float speed) { } public void setTurnSpeed(float turnSpeed) { } public void setFlyHeight(float flyHeight) { } public float getFlyHeight() { 180 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 } public void setFlyHeightT(float flyHeight) { } public float getFlyHeightT() { } public void update(GameObject player, long elapsedTime) { } protected void backupAndRecomputePath() { } public boolean isFlying() { } public void notifyEndOfPath() { } public void notifyWallCollision() { } public void addHealth(float amount){ }
public void notifyObjectCollision(GameObject object) { } }
7.3 AI For The Unit in 3D Game

Overview: It is no doubt that AI serves as one of the primary task in any 3D Game. This AI unit must incorporate with the Path and Map of the 3D Environment. A good 3D Game, must have a good AI for the enemy units. Failure to do so will result in a poor game play for that particular 3D Game. A good AI will enhance the realism in the 3D Game as well.
7.3.1 Patterns
A pattern refers to how the enemy units behave when it encounters a critical event. (such as being hit by the player). In David War Game, there are 3 types of pattern being defined, these are aggressive, moderate and scared. These patterns can be known as the enemy characteristic. Whenever the player charges against the enemy unit, the enemy will have scared, by default. Whenever the enemy exists in a group, the enemy will have aggressive by default. Moderate will be set whenever the enemy is in a normal condition. (Such as patrolling the area). However, each enemy unit will have different patterns on the whole. (A Tiger I Tank can be described as very bold, while an infantry is really a coward). The pattern of an enemy might changed during the game play as well. (See Evolution for more details). Another aspect of pattern is the enemy behaviors when attacking the player. These type of patterns are strafe, charge and surround. Strafe pattern will attack the enemy in a zig zag manner. The charge pattern will attack the enemy in high speed, going in a straight direction. On the other hand, a surround pattern will attack the enemy in a circle fashion, going towards the enemy in 360 degree while attacking it. (See figure below to get an overview of the different patterns).
Figure 7.3.1.1 Charge Pattern
Figure 7.3.1.2 Strafe Pattern
Figure 7.3.1.3 Surround Pattern
7.3.2 Probability basis

Whenever an enemy unit makes a decision, the decision being made must be based on a probability basis. The sum of the decision available must be equal to one. A more favorable action will be given higher weight age than the less favorable one. Therefore, it is assumed that every time the enemy unit made a decision, it will make the best decision based on the available decision.
7.3.3 Evolution
Prior to the version 1.0.4 of the David War Game, Evolutionary Algorithm has been applied to the system so as to enhance the game play of the 3D Game. Every time the enemy unit dies, it will be regenerated again in the future. However, this new offspring will not be identical to the old one. Instead the system will generate the best available offspring from the old one. The fitness of the offspring will be determined from its lifespan in the game, how vulnerable it is to the player, the amount of damage done on the player, as well as its tactic being applied to the player. However, this new and better offspring might not be effective against the player if the player changes its playing style. For example, when the player is being defensive, the aggressive enemy will survive longer and therefore being favors more in the next generation of the offspring. When the player changes its style towards attacking, a defensive enemy will survive longer than any other enemy units. However, because the new and more adapted offspring will consists mostly of aggressive enemy due to the player old playing style, these new enemy units might not be effective against the player and dies faster than it was expected. Therefore, the system must maintain a list of poor enemy units in the system so as to balance the evolution process. All the enemy capabilities including the best enemy are stored in the class Brain. The concept of evolution in the 3D Game will be nearly similar to the concept of Genetic Programming. An enemy capability will be stored in a chromosome, equivalent to a data structures. Application of crossover and mutation will be used in this chromosome. Crossover rate will be 25% while the mutation rate will be 0.01%. Crossover will tend to enhance further the capability of an enemy unit, while the mutation tends to diversify the enemy unit capability. A good enemy capability will be maintained throughout the population. This is known as elitism. The poorer enemy units, will be vanished as time goes by.
7.3.4 Unit intelligence

Overview: An enemy unit will have certain capabilities when dealing with a player. These capabilities will make the game to be more realistic. Below are few of them:
7.3.4.1
Seeing
An enemy unit can only sees a player if it faces the player within -45 to +45 degree from the 0 degree. (0 Degree refers to the normal of the enemy). Refer to the diagram below for more details:
Figure 7.3.4.1 Seeing capability
7.3.4.2
Hearing
An enemy unit is also able to hear the players walking steps. Even if the player is in another room, the enemy unit is able to keep track of it. (In fact, an aggressive enemy will start a search on it). An enemy unit might hear the player even if it does not see it. (Figures below give an example of the enemy hearing capability).
Figure 7.3.4.2.1 An enemy hears the player in front of him 185 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
Figure 7.3.4.2.2 An enemy still hears the player even if there is an obstacle
7.3.4.3
Radius Detection
The most interesting part of an enemy capability will be the radius detection. A radius detection enables the enemy unit to detect the player within a given radii. Smarter enemy will have greater radii compared to the dummier one. Figure below gives an overview of the radius detection.
Figure 7.3.4.3 The radius detection
7.3.5 A bots capability

A bot refer to an enemy unit. As mentioned previously, different bot will have different capabilities. Some bot, such as the Z Tekken, will have all the good capabilities of any other bot, while some bot, like the infantry, will be weaker than others. There are also all rounder bot, such as the Sherman Medium Tank. A bot capability will be defined in terms of lifespan, attack ratio, attack amount, speed, turning angle, survivability rate, and learning skills. Usually, an average bot will have the proportion of capability: Mood Type Amount Aggressive 20% Moderate 60% Scared 20% Table 7.3.5.1 Average Bots Capability A smart bot will have the following capability: Mood Type Amount Aggressive 50% Moderate 25% Scared 25% Table 7.3.5.2 Smart Bots Capability And finally, the weak bot will have the following capability: Mood Type Amount Aggressive 25% Moderate 25% Scared 50% Table 7.3.5.3 Weak Bots Capability
7.3.6 Morale
For version 1.0.7 and above, David War Game has equipped the enemy units with morale capability. For this new and enhanced feature, the enemy units will fight boldly when working in a group, but will become a coward instead when fight alone. Like the Unit Editor, David War Game is proud to announce this new feature which differentiates it from other commercial available games.
7.3.7 Players toolbar and other objects

There is also toolbar for the player status in the 3D Game. This toolbar gives the amount of the player life, the amount of ammo left in the weapon, the player status, as well as animation for the weapons available. Refer to figure below for the toolbar:
Figure 7.3.7 Player Toolbar
Chapter 8 Other Features in 3D Game

8.1 Game Scripting, Plugs In, Save and Load
Overview: Game Scripting is used to enhanced the realism and game play of a game. It is also useful for the efficiency of the running time of the game. David War Game has Scripting implemented in it. However, scripting is only used for Mission 1 of the Game (Berlin). The scripting in David War Game was developed using BeanShell. However, the scripting used in the system was merely based on the work developed by David Brackeen. (visit www.brackeen.com/javagamebook). Only little modification was done to the code, which includes the thread handling and multiple processing running. The system needs Load and Save for its 2D and 3D Game. However, due to the time constraint, the Load and Save features are only available in the 3D Game. The 2D Game does not need these features as it is too simple by nature. Note that the Load and Save Features provided in David War Game will be a substandard one, due to the limitation in Java.
8.1.1 Secret levels

It was agreed that the development of Secret Levels will further enhanced the game play of the 3D Game. Suggestion has been given that the secret level will only be activated when the game players have achieved something. (Such as trigger a hidden lock). This feature as well, was unable to be implemented due to the time constraint for the project. It was also unfortunate that the portability of the 3D Game has been limited, therefore the Secret Levels cannot be done because of this reason as well. However, the programmer of the system manages to implement a secret level in the 2D Game.
8.1.2 Medal
Every time a player manages to complete a level with remaining 95% of life, he will get a medal as a reward for his duty. (95% life remaining means that you must be hit only at most once!). A player can get 8 numbers of medals at most and none at least. The information of the medal will be stored in an external file and reload every time the game is executed.
8.1.3 Plugs In
One candidates of the questionnaire has given his suggestion that the system must have a plug in feature for the users. Therefore, from version 1.0.6 onwards, the system has been equipped with the plug in capability. The system will reuse the parser coding in the MAP file creation for the validation of the Plug In Files. It will also validate against the file extension, where the system will only accepts a file with MAP extension only. Plug In enables a user to create his own enemy units and map in a different environment, where he will specify the Map based on his criteria. This gives the game more flexibility in game play.
8.1.4 Story Loader

Prior to version 1.0.8 and above, the system has a story loader for every mission in the Game, except the Plug In. Before a game is loaded, the system would load a story based on the mission, while giving a briefing to the player about his goals that he is supposed to achieve. Story loader made full use of the functionalities provided by Java Threads and Swing packages.
8.1.5 Java Serialization API and Persistence State

Java has provided an interface that enables the Load and Save features of the game to be possible. This interface is known as the Serializable interface. Every class and object that needs to be saved needs to implements this interface. This includes the library classes that the particular class links to. When a class implements this interface, all the data structures and variables will be stored in an object format. It also enables the user to store the data in object format to a local file. (Such as Text File, but the user can rename it as having extension SAV). However, the Java has limitation in the Serializable interface as well. Not all the librarys classes in the Java Package support this interface. One good example will be the Graphics abstract class. This limitation will lead to the system Load and Save features being implemented in a substandard manner. Therefore, for version 1.0.6 onwards, a new Save and Load features has been implemented. The characteristic of these new features are as follows: 1. 2. 3. 4. 5. The system can only save the level and file name. The system will load the file in a new level, not in between level. There is a snap shot of game play since last save. File name to be saved is limited to five only. The User Interface created will be a simple one and consumes little memory at the same time.
David War Game Final Report Final Year Project 2004/05 Based on the above explanation, it is obvious that the Save and Load features is not fully implemented and deployed, but the Programmer cannot do anything as this is a limitation and drawback in the Java Programming Language.
8.1.6 Snap shot of Game Play

Every time a game is saved, the snap shot of that particular screen is taken and saved. The images taken will be saved in the folder C:\Documents and Settings\David Hong\MyGame\saved. Figure below gives an example of a snap shot taken at a particular level.
Figure 8.1.3 A Snap Shot This snap shot is a remarkable breakthrough in the system as not many games have this snap shot implemented in it. Note that the snap shot will only be taken when the user press the Save Button.
8.1.7 Save and Load UI

As mentioned previously, the programmer of the Save and Load features decided that the UI (User Interface) for this feature will be as simple as possible and not consumes too much memory. The Save and Load Features consume about 534KB of memory when invoked, compared to the original value of 520KB. However, this value is still acceptable as it is just an increase of 14KB. (This is due to the extra feature such as the snap shot, but other feature such as file naming, has been reduced in great amount). On the other hand, the Save and Load features might make the system in an unstable state. (These bugs have been remove since version 1.0.7, after countless hours have been spent to detect and remove it).
8.2 Weapons
Overview: There are two types of weapon being used in David War Game, the Infantry and Anti Tank weapons. Each weapon has its own uniqueness, strength and weaknesses as well. However, all the weapons do not support friendly fire, in other words it cannot damage any friendly unit when activated. (This do not applied to the enemy units) For more information on the weapons in David War Game, refer to Appendix G.
8.2.1 Infantry Weapons

Overview: Infantry weapons are used to destroy any infantry units as well as the bazooka units. Infantry weapons are not effective against any vehicles, such as a Tank, so it is advisable that the player used Anti Tank Weapons instead to destroy them. Infantry weapons have higher firing rate than the Anti Tank Weapons, but are slow when respond to reload time.
8.2.1.1
Hand Gun
The hand gun is the weakest weapon in David War Game. It is useful to counter an infantry unit, but it still lacks of range and fire power. In fact, it is relatively slow to firing rate and does not cause much damage to the enemy unit.
Figure 8.2.1.1 A Hand Gun Specification: Firepower: 15-20 life damage Fire rate: 13 rounds per second on average, depends on the player Reload time: 5 seconds Magazine round: 15 per round
8.2.1.2
Rifle
Rifle causes a heavy damage to the enemy unit due to its bullet sharp edges. Like the hand gun, its firing rate is relative slow. Moreover, it has a bullet packet of only 6, and when the bullet is finished, the player needs to reload them. If the player wants an instant kill and is very sure that he is able to hit the enemy unit accurately, he should opt for the rifle.
Figur 8.2.1.2 A Rifle Specification: Firepower: 80-120 life damage Fire rate: 8 rounds per second on average, depends on the player Reload time: 7 seconds Magazine round: 6 per round
8.2.1.3
Sub Machine Gun
Compare to the Rifle and Hand Gun, a submachine gun will be a better weapon to use against the enemy infantry units. It has greater fire rate as well as bigger magazines size. However, it still lacks of fire power compared to the rifle. (It does not cause heavy damage to the enemy unit).
Figure 8.2.1.3 Sub Machine Gun Specification: Firepower: 60-75 life damage Fire rate: 45 rounds per second Reload time: 4 seconds Magazine round: 32 per round
8.2.1.4
Machine Gun
Machine Gun is an extended version of the sub machine gun. It gives more damage to the enemy unit as well as having a higher firepower and firing rate. It could be used as an assault weapon against the infantry units. In fact, it is the best assault weapon for the player.
Figure 8.2.1.4 Machine Gun Specification: Firepower: 70-85 life damage Fire rate: 50 rounds per second Reload time: 4 seconds Magazine round: 32 per round
8.2.1.5
Heavy Machine Gun
Heavy Machine Gun could be described as the best infantry weapon ever known. It has excellent fire power, firing rate as well as high magazine round. However, it is extremely heavy for the player to carry, therefore reducing the player speed. (This characteristic is not implemented in the game, therefore reducing the realism effect in the game).
Figure 8.2.1.5 Heavy Machine Gun Specification: Firepower: 80-110 life damage Fire rate: 65 rounds per second Reload time: 6 seconds Magazine round: 40 per round
8.2.2 Anti Tank Weapons

Overview: Anti Tank weapon was specifically used against the heavy vehicle, such as tank, or bunkers as well. However, the impact on infantry will be disastrous when used against them. Like the infantry weapons, the anti tank weapons forbid friendly fire. (This do not applied to the enemy, like in the infantry weapons). Anti tank weapons are available in limited quantity, therefore the player must be able to use them carefully.
8.2.2.1
Mine
A mine is a static object when placed. However, it is disastrous to the enemy unit when activated. A mine is usually planted on the ground. It will only explode when the enemy unit steps on it.
Figure 8.2.2.1 A Mine Specification: Firepower: 550-600 life damage Fire rate: N/A Reload time: N/A Magazine round: N/A
8.2.2.2
Sand Grenade
A sand grenade is used to destroy a moderately armored vehicle. It is thrown to the air before it landed on to the enemy unit. However, it is less damaging compared to the other anti tank weapon. It can damage the surrounding object as well if the object is somewhere in its coverage area when it explodes.
Figure 8.2.2.2 A Sand Grenade Specification: Firepower: 300-350 life damage Fire rate: N/A Reload time: N/A Magazine round: N/A
8.2.2.3
Time Bomb
The time bomb will be the most damaging and harmful weapon in David War Game. It can easily destroy any light armored vehicle by just a single charge, while 4 charges of time bomb can easily destroyed a heavily fortified object such as the bunker. It needs 10 seconds to explode upon activation by the player.
Figure 8.2.2.3 Time bomb Specification: Firepower: 600-700 life damage Fire rate: 10 seconds activation Reload time: N/A Magazine round: N/A
8.2.2.4
Bazooka
A bazooka serves as an enhanced infantry weapon. It fires likes the infantry weapon, but with a projectile instead of a bullet. It is less damaging compared to the mine and time bomb, but show promising sign in terms of damage compared to the sand grenade. If the player can aim accurately, then he should opt for the bazooka as his anti tank weapon.
Figure 8.2.2.4 Bazooka Specification: Firepower: 350-400 life damage Fire rate: 15 rounds per second Reload time: 5 seconds Magazine round: 1 per round
8.3 Missions in David War Game

Overview: All missions in David War Game will be created based on the true story of the World War 2. It details will be design in moderate details and consume little memory at the same time. (Although some level, such as the Leningrad, took out a lot of memory). All missions will be either on the Allies or the Axis, with three countries being actively involved, that are German, United States, and the Soviet Union.
8.3.1 Mission 1
Figure E.1 Mission 1 Map (Default Mission) Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Hard
8.3.2 Mission 2
Figure E.2 Mission 2 Map Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Moderate
8.3.3 Mission 3
Figure E.3 Mission 3 Map
Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Easy
8.3.4 Mission 4
8.3.5 Mission 5
8.3.6 Mission 6
David War Game Final Report Final Year Project 2004/05 Mission Type: Allies (United States) Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Easy
8.3.7 Mission 7
8.3.8 Mission 8
8.3.9 Mission 9
Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Moderate
8.3.10
Mission 10
Figure E.10 Mission 10 Map Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Easy
8.3.11
Mission 11
Figure E.11 Mission 11 Map Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Easy
8.3.12
Mission 12
Mission Type: Axis Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Moderate
8.3.13
Mission 13
8.3.14
Mission 14
Figure E.14 Mission 14 Map Mission Type: Allies (Soviet Union) Objective: Destroy All enemy units Ammo and Health Availability: Yes Difficulty: Hard Note: All requirements and specification are based on the programmers point of view.
Part IV: Testing, Problems and Planning
Chapter 9: Alpha, Beta Phase and its role in Testing

9.1 Bugs, issues and constraints encountered
Semester 1 (Work Done) During the initial phase of this project, the program developed has undergone alpha, beta, and gamma testing. The program (David War Games) has been developed since the end of September 2004. The program was at the version of 1.0.458, which means that the program has undergone 458 upgrading and changes. To describe the progress of the program clearly, the development of the project during the first semester can be divided into three phases: (Note: The project uses the RAD approach, so users involvement is important in this project.) Initial Phase: During this phase, the resources for the program have been greatly searched throughout the web sites. Below are some of the works done during the initial phase. 1. 2. 3. 4. The searching of Image files from the web sites, such as Background Images. The searching of appropriate source code from the web. The development of Video Player. The development of Audio Player.
Intermediate Phase: Below are some of the works done during the Intermediate Phase. 1. 2. 3. 4. 5. The development and incorporation of the User Interface into the system. The integration of Video and Sound Player into the system. The coding of the memory and speed allocation for the system. The development of about and options menu. The activation of Key and Mouse mapping.
Final Phase: Below are some of the works done during the Final Phase. 1. The coding of the 2D game. 2. The coding of the 3D game. 3. The integration of 2D and 3D game into the system. 209 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 Semester 1 (Bugs, issues and constraints reported) As expected, the program will have some bugs upon execution. This can be further clarified by having some testing. So, the program has undergone testing in three phases, namely the Alpha, Beta and Gamma testing. The users will run and test the system. They will report the bugs, if found, to the programmer concerned. However, the debugging will be done by the programmer of the system. Below are the lists of bugs, issues and constraints encountered during the system development, divided into three phases: Initial Phase: 1. The audio player can support AU, AIFF, and WAV formats only, so a support for MP3 must be integrated as well. 2. The Audio Player will exit when sound playing is completed, thus a different implementation must be carried out for this problem. 3. There are no GUIs for the Audio Player. However, this is not a must for the system. 4. The JMF Video Player only runs when the software was installed, nothing can be done on this. 5. The JMF Video Player supported only MPEG format, thus a support for other extension such as MOV must be integrated as soon as possible. 6. Some sources are copyrighted, but it does allow permission for academic purposes, so this issue must be handled with care. 7. Some Images are not relevant in the system, so these particular Images must be removed from the system. Intermediate Phase: 1. 2. 3. 4. 5. The loading time for the menu is time consuming. There are difficulties in integrating the video player into the system. The system seems to hang after running for some time. Key and Mouse Mapping do not seem to work properly. The Player Image in front of the menu does not seem to be relevant to the system developed.
Final Phase: 1. 2. 3. 4. Out of Memory error has been reported when exiting the 3D game. The 2D game does not seem to work on other JDK version besides JDK 1.4.2. The 3D game is too simple in design. The 2D game component does not suit the story of World War 2.
Semester 2 (Work Done) During the second semester, a lot of enhancement has been made to the system. More work has also been given to the copyright issues, such as obtaining a freeware product and coding. Some part of the system has been further upgraded while some advanced and new features have been added as well, such as the plug in feature. However, the work done on developing the system during the second semester is lesser compared to the first semester as most of the features needed in the system have been developed during the first semester. (70% of the system has been finished during the first semester). More emphasis has been given to the report writing as well during the second semester. The work done during the second semester can be divided into three phase: Initial Phase: 1. 2. 3. 4. 5. 6. The creation of different levels for the 3D Game. Enhanced Save and Load features. Upgraded settings menu. More detailed credits menu. Medal creation after level completion. Ammo and health boxes availability in the 3D Game.
Intermediate Phase: 1. 2. 3. 4. Enhanced library menu. Plug In feature. Online networking feature. More realistic weapon display.
Final Phase: 1. 2. 3. 4. Installer for the systems. Conversion to Native Format. Report writing for the dissertation. Deployment and testing for the system.
David War Game Final Report Final Year Project 2004/05 Semester 2 (Bugs, issues and constraints reported) As the programmer gains more experience during the implementation phase, the system develop results in a more stable and efficient system. There are lesser bugs detected during the second semester, due to the system being more carefully implemented by a more experienced programmer. Secondly, 70% of the system has been implemented during the first semester, giving only 45% on the work remains to be completed during the second semester. (including an additional 15% extra work). The bugs, issues and constraints reported in the second semester can be divided into three phases: Initial Phase: 1. Some levels are to complicated in design and make the system results in memory out error. 2. Save and Load menu seems to make the system hangs and jammed. 3. Setting feature seems to block the key and mouse listeners, and in some cases, it reset all the key and mouse mappings. Intermediate Phase: 1. Library menu seems to consume more memory compared to the initial version. However, the system does not crash in the event of failure. 2. On some but rare occasion, the plug in features hangs after selection of plug in files. 3. Due to the programmer limited access to the broadband connections, the online networking feature cannot be deployed. (Although the networking feature has been fully completed). Final Phase: 1. Installer available for the system is based on trial version, therefore limiting the deployment aspect of the system developed. 2. Time seems to be a contributing factor for the partially completed system. (The system has all the necessary features, but some serious bugs seem to appear and remain unfixed until now).
9.2 Handling of bugs, issues and constraints

During every phase of Alpha, Beta and Gamma testing, the programmers involved will fix the bugs detected when reported by the users. The Handling of Bugs, Issues and Constraints are divided into 2 semesters, each with three phases: Semester 1: Initial Phase: 1. The Audio Player has been enhanced further to support the MP3 format. This is solved by having the Freeware JLayer MP3 player downloadable from the web implemented in the system. 2. Two Audio Players have been created, one to handle the background music, and the other the game music (e.g. Action, Shooting). The previous version has a single player implemented in it, in a class named jlap. In the new version, two classes has been created, namely jlap and jlap2, which is similar to each other except that one has no repeat playing compare to the other. 3. GUIs for the Audio Player have been created, but the system does not really need the GUI. This GUI supports the shuffle, repeat playback, with the basic features such as New, Open, Save and Save As. This GUI implemented on the system seems to be a waste of effort in the project. 4. Support for other extension such as MOV for Video Player cannot be done, as this will make the system involved more complicated. Many commercial games use the MPEG and BIK extension, with only minority of them using MOV extension for their movies. In fact, none of the games tested for the project uses MOV extension. Thus, support for MOV will be ignored. However, this feature can be done, but as the system uses MPEG files for its Video Playing capabilities, there is no point of having the system supports this extension. 5. Irrelevant Images have been removed from the system. This includes the soldier icons and some background images. 6. Copyright items will be handled with more care in the future. If the items are copyrighted, then its academic license availability must be considered. If this particular item allows for academic purposes, then this item would be used instead. If it is not intended for academic license, then an e-mail would be send to the company of this item to request for permission to use this item.
David War Game Final Report Final Year Project 2004/05 Intermediate Phase: 1. A more efficient loading system has been developed for the loading of the menus. This is done by having a more efficient thread processing, as well as eliminating recursive methods call. 2. Video Player will only be played for the Introduction of the Game that is when the Game is starting. The Video Player cannot be integrated into the system, it is a standalone system, so the video player will be used only during the start of the game. 3. The 3D game will not hang when exited, it was found that some unnecessary code existed in the system, thus giving some problems when the system exits. Run method has been called twice, thus overloads the system by two times. This will take out the memory and resources by two times, thus makes the system hang. 4. The key and mouse mapping problems will be fixed in the next semester, as it does not really pose a serious problem to the system. This problems only occur when using the about menu and some other panel related system, so there is no serious threat to the system at the moment. 5. The player in front of the menu will not be removed, as it gives some help in the key and mouse mapping. (The cool blue color image of a face wearing a black sunglasses) Final Phase: 1. Nothing can be done for the 2D game that does not run on some version of the JDK, it is the JDK short fall. The 2D game could not exited properly, and it was found out that the version of the JDK has cause this problem, thus the Sun Developers must fixed this problem in the future. 2. The 3D game looks too simple in design as the system is still in its initial stage of implementation. 3. The 2D game is designed for Adventure type of Game Style, such as the Mario Bros., so nothing can be done on this. (The realism of the 2D game)
David War Game Final Report Final Year Project 2004/05 Semester 2: Initial Phase: 1. For those level that consume extra large memory spaces, the Java code will be converted wholly into Native Form, which can allocate up to 1000MB of free memory spaces. 2. Save and Load feature will use the existing pause method when invoked, thereby the system will not hang and jammed when called. 3. All the mouse and keyboard mapping for the game will be set to default when starting a game. The keyboard and mouse mapping in the settings menu is just for test only. (The programmer tries his best to fix this, but only manages to solve the problem up to 95%, therefore decision has been made to enable the keyboard and mouse mapping to be set to the default value due to the time constraint in the project). Intermediate Phase: 1. The library menu memory consumption will be leave as it is, as it does not made the system crash in the first place. 2. Java has poor event listener for real time system and simulation as well, so nothing can be done on the plug in file selection feature as the problem is cause by some Java limitation. 3. The online networking feature will be treated as completed, but not deployed. It was not the programmer faults in the first place as he does not really have access to the broadband connection, which gives a limitation to test the deployment of the networking feature. (The system needs a highly fast broadband connection for its networking capability). Final Phase: 1. The project is lack of funding, so Installer will be available on trial version. Secondly, it does not make sense to buy an Installer just because of a Final Year Project.
9.3 User feedback

The users of the system have been giving adequate feedbacks and comments. Furthermore, they have been helpful throughout the course of the project. However, small bugs and problems will be ignored for the Project Testing Phase. Only those problems that give serious threats to the system will be considered. A form was given to the users so that they could list out the bugs that they have found when they tested the system.
Chapter 10: Future work and planning

10.1 Work Done and Future Work
Work Done
Most of the works planned for the project have been successfully completed. Below are a few of them: 1. The choice of weapons for the player. This includes giving the player a list of weapons ranging from Hand Gun to Bazooka when they played the game. Each weapon will have its own advantages and disadvantages. The weapons will have different characteristics, such as movement, damage caused and speed of reloading time. 2. Map Editor. The player can view the map of the scene by just pressing M. This Map Editor will display all the walls, enemy units, player, projectile, weapons, and other objects such as Crate Boxes. 3. Unit Editor. This feature enables the player to create his own enemy unit. The new unit will be stored in a new file, with extension OBJ, such as Tank1.obj. The user will have the freedom of choosing the country of origin, head of unit, as well as body of unit. A Building Background Music will be played upon choosing this option. This feature will be available at the Main Menu. 4. Library Menu. This feature gives the player a view of the enemy unit created in David War Game. It has some Images of the World War 2 Weapons, as well as the animation of enemy unit in David War Game. 5. Save and Load features. These features will allow the player to save and load a game. This can be easily done by using the Java Serialization APIs. The user can save a game while playing as well as load a game when he has already lost in a game, for example. 6. Loader Menu. The System will display a nice loader menu while loading the game. The user will have a chance to enjoy a good User Interface while loading the game. 7. Tutorial. The system will be equipped with Tutorial, where the player can train himself before playing the game. This Tutorial will teach the player the necessary skills needed to play the 3D game. 8. Enhanced Settings options. This feature will give the player some additional settings, such as enabling cheats, sound and video configuration, and difficulty level. 9. Scripting of the game.
David War Game Final Report Final Year Project 2004/05 This feature enables the wall, floor and ceiling to be move apart. In fact, static objects can be move by using this technique. Enhancement could be done on the secret levels, by creating an invisible wall. Other ideas, such as triggering a stair, could be integrated into the project as well. 10. Meta Programming. This feature could be a tedious task to do. It involves programming the whole story line of a particular mission. This includes programming the AI (Artificial Intelligence) of the enemy unit, the pattern of enemy unit, such as Defensive or Aggressive, and the interaction of the environment with respect to the player. 11. UI For The System The UI developed will consist of a background images, supported by menu, which has various components in it, such as buttons, text field, and scroller. Animation will be created in the UI if needed. 12. Audio Player The audio player has been successfully created for both the 2D Game and the 3D Game, which support MP3, WAV, OGG, AU, AIFF and MIDI format. 13. Video Player The video player will be based on the freeware SurePlayer which supports MPEG format. 14. Medal The medal will be given to the player who successfully completed a level with remaining 95 percent and above life.
Future Work
However, some of the work has been proposed for the system, but have not been completed given the time constraint. Below are few of them: 1. Alliance and plot. This enables the player to have it owns unit to battle with the enemy unit. In other words, the player would battle with the enemy in a group, not in a single person as in the old version of the system. Enhancement could be made such that the player could lure the enemy unit to battle against its own friends as well as the players own group betray each other by fighting with each other. This is known as Alliance and Plot. 2. Animation of weapons. When the player chooses a weapon, the weapon will be displayed in front of him. When he fires the weapon, the weapon will recoil and bullets will start flowing out from the weapon. When he reloads the weapon, the weapon will change its magazine. 3. Real time Map. When the player chooses a Desert Mission, such as Tobruk (The Battle between Germany and Britain in North Africa), the map will show real time scenes, displaying some sands, oasis, and cactus. When the player chooses a Russia Mission, such as Stalingrad (Battle between Germany and Soviet Union), the Map will display some damaged buildings, as well as a winter environment. 218 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
10.2 Unexpected features

As the project progressed further, some unexpected features have been found in the system. Below are the lists of these features: 1. Plug In Options. One of the candidates of the questionnaire had suggested that this feature to be added into the system. This feature will enable the player to create his own map and unit, and upon creation, the program will load these files and run them in the system. 2. Online Gaming. This feature is quite hard to implement. Due to some limitations in Java, this feature is only possible for the 2D game. However, the Online Gaming feature can be programmed in C++ for the 3D game. This will require a lot of resources, time and coding efforts, which will only be considered at the end of the project. 3. Some funny features. These features, although sound interesting, may not be appropriate for the project. These features will display some unknown and strange behavior in the system, such as a cow mooing sound when selecting a button, for example. These features will only be considered if the feedbacks from the users are good.
10.3 Suggestion for upgrading and enhancement

It has been agreed that most of the upgrading and enhancement will be considered for the 3D game. The implementation for the 3D engine will be made more efficient, if possible. The execution speed will be considered as the most important, besides the memory usage. The 3D game will contain most of the features available in the commercial games, making it as realistic as possible. On the other hand, the realism of the story line of the 3D game must be handled seriously as well. This includes the Enemy Unit created in the game, such as Tanks, as well as the real life environment/scene.
10.4 Problems faced

A few problems have been encountered during the project requirement phase. The same applied to the project analysis and design phase. However, a lot of problems have been encountered during the implementation phase. Problems encountered include Copyright issues, difficult to fix bugs, communication with the users, and resources (memory) allocation for the system. However, most of these problems, but not all, have been successfully solved at the end of the project. 219 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
10.5 Deployment
Installer During the analysis phase, few installers have been proposed for the system. Excelsior JET, Install Shield, and Install Anywhere will be the preferred choice for the system. After countless of debate and arguments among the beta users, the choice of installer for the system will be as follows: 1. Excelsior JET Installer. The Excelsior JET Installer will be used for the native executable files. It will serve as the main installer for the system. However, its license will expired in 3 months time upon installing. Therefore, the other two installers will serve as a backup for this issue. 2. Install Shield X. Install Shield X will serve as the installer for the general software. It will not have trial period and license in it. Its period of usage is permanent and free for the users. However, the users need to register first before using the software, and it is copyrighted as well. 3. Advanced Installer. Advanced Installer will be used for the Java Application Files. Since part of the system is implemented in Java, therefore there exists a possibility to use this installer for the deployment phase. Other programming coding for the system, such as C++, will be converted into JNI (Java Native Interface) format that is readable by the system. Cost of David War Game David War Game will be available freely to all the users before the end of August 2005. After this period, the system will be wholly implemented all over again from the scratch. The new version of David War Game will then be available at a cost, which will be decided at a later stage. All the copyrighted material in David War Game will be removed and replaced by a freeware material or created by the programmer himself. Distribution David War Game will be distributed to the lecturers of the university, the project supervisor, students of the university, and beta users at no cost during the evaluation period. However, it is unsure of how the distribution will be in the future, probably after the end of August 2005.
10.6 Maintenance
The maintenance of the software will be done for every 2 months after the release of the first version. Beta testing will be done as frequently as possible, so as to ensure that the system will have minimal bugs in it. A plan of converting the software into C++ coding will be carried out after the first release. In other words, the newer version of David War Game will be wholly implemented in C++ Programming Languages.
10.7 David War Game Web Page

It was agreed that David War Game will have its own personal webpage when deployed. This webpage will give the user a glance on the project being done. It must be accessed everywhere and anytime by any users around the world. However, this website will not have online gaming as part of its content. In fact, the users around the world cannot even download any software for David War Game from its personal web page. The URL for the web page will be www.geocities.com/davidwargame.
Part V: Summary
Chapter 11: Summary

11.1 The project on the whole
The progress for the project was excellent. Everything was planned and done successfully. Background reading material was good, with a lot of ideas gained from the reading of journals, magazines and books. Good responses in terms of adequate feedback have been given out by the Game Users who had filled up the questionnaire. The people involved in the Beta Testing have been quite friendly, giving good suggestions and responses to the testing phase of the project. Time management was good. Much of the time has been devoted to the analysis phase. In fact, the project has started since the 2nd year of the BSc Computer Science course. Part of the implementation phase has already been carried out during the first semester, giving the project a big forward step towards completion. The Game Programmers around the world have been giving adequate help as well. They give some advices on how to start the project, what the project supposed to be in general, and some valuables comments on the project. Overall, the progress of the project so far was excellent, and it faces only minor obstacles during the whole year. However, the author of this report admits that he did not manage to fix some serious bugs in the system due to the time constraint given in the project. In fact, some of the features remain uncompleted.
11.2 Summary
The progress of the project was good, at least 70% of the work has been completed during the first semester, including those done during the second year of the course. In general, all the problems encountered in the project were successfully solved, except the copyright issues, which were nearly solved. The supervisor has been very helpful during the semester, by giving guidance and advice on the project even during the semester break. In fact, he has personally done some research on this project. The program for the project has been completed at least 70% in the first semester, which includes User Interface, Sounds, and Videos. The analysis part for this project has been successfully completed, while the implementation part has been at least 70% in completion. Testing and Debugging part has been carried out during the second semester, followed by Distribution and Maintenance phase. The system will be fully deployed during the demonstration day, while copies of the beta version have been given to the beta testers. 95% of the system has been completed in the second semester, while the remaining 5% will be treated as part of the project future work.
11.3 Conclusion
The project was successful, on the whole. The project has been completed by the end of April 2005. (The system has been completed in March 2005, while the report writing in April 2005). Beta version of the software has been given out to the beta testers during the month of April, while distribution of the software for the users will be planned for the demonstration day.
References
R1 : Books
[1]- Oestereich Bernd 2002 Developing Software with UML, 2nd Edition, Addison Wesley, p. 158. [2]- Oestereich Bernd 2002 Developing Software with UML, 2nd Edition, Addison Wesley, p. 161. [3]- Oestereich Bernd 2002 Developing Software with UML, 2nd Edition, Addison Wesley, p. 265. [4]- Oestereich Bernd 2002 Developing Software with UML, 2nd Edition, Addison Wesley, p. 172. [5]- Kendall, Kenneth E. , Julie E., 2003, System Analysis and Design, 5th Edition, Prentice Hall, p. 217 [6]- Kendall, Kenneth E. , Julie E., 2003, System Analysis and Design, 5th Edition Prentice Hall, p. 217 [7]- Kendall, Kenneth E. , Julie E., 2003, System Analysis and Design, 5th Edition Prentice Hall, p. 220 [8]- Kendall, Kenneth E. , Julie E., 2003, System Analysis and Design, 5th Edition Prentice Hall, p. 219 [9]- David Brackeen, 2003, Developing Game in Java, 2nd Edition, New Riders [10]- Andre La Mothe, 2002, Trick of the Windows Game Programming Gurus, 2nd Edition SAMS Publishing [11]- ]- Andre La Mothe, 2002, Trick of the 3D Game Programming Gurus, 2nd Edition SAMS Publishing [12]- Daniel Sanchez, Crespo Dalmau, 2003, Core Techniques and Algortihms in Game Programming, 1st Edition, New Riders [13]- Andrew Rollings, Dave Morris, 2003, Game Architecture and Design, 1st Edition, New Riders [14]- Matthew Omernick, 2004, Creating the Art of the Game, 1st Edition, New Riders [15]- Alex J. Champandard, 2003, AI Game Development, 1st Edition, New Riders [16]- David Freeman, 2003, Creating Emotion in Games, 1st Edition, New Riders 226 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
R2 : Webs
Video Files http://www.gamezone.com http://www.eagames.com/official/moh_alliedassault/home.jsp http://www.battlefield1942.co.uk/archive.php http://www.strategyfirst.com/downloads/ListFiles.asp?iFileTypeID=7&sLanguageCode= EN http://www.fileshack.com http://www.gamespot.com/pc/action/mohaabreakthrough/ Audio Files http://www.musicnotes.com/features/promo/starwars/?mnuid=7QGJ0BBTVCB5NCLLZ SD9XR5YHY11LU461UKSLU46 http://www.lucasarts.com/products/swkotor/S_supplies.html http://www.gamebanshee.com/starwarskotor/downloads.php http://www.headeye.com/midi_pages/midis_movie_themes.html http://www.quigon.org/ http://www.reelclassics.com/Gallery/music.htm http://www.worldmilitaria.com/newsite/media.html http://www.pro-american.com/Free_Music/free_music.html http://www.starpulse.com/Video_Games/Rainbow_Six_3/Downloads/ http://bf.filefront.com/files/Battlefield_1942/Media/Audio;1072 http://www.javazoom.net http://www.tigertank-h-e-181.com/songs_and_lyrics.htm http://www.lucasarts.com/products/forcecommander/downloads.htm 227 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 Image Files http://astronomy.swin.edu.au/~pbourke/texture/ http://www.combataircraft.com/fighter.asp http://www.animationlibrary.com/a-l/index.php3 http://world.guns.ru/ http://www.geocities.com/pizzatest/panzerfaust11.htm http://www.planetmedalofhonor.com/files/wallpaper.shtml http://www.panzers.com Papers http://www.sciencedirect.com/ http://www3.interscience.wiley.com/cgi-bin/home http://www.swetswise.com/ http://proquest.umi.com/login http://www.ingenta.com Copyright [C1]- http://www.gnu.org/copyleft/gpl.htm [C2]- http://www.whatiscopyright.org/ Others [O1]- www.java.sun.com [O2]- www.brackeen.com
R3 : Papers
Scott Schaefer, Joe Warren, Teaching Computer Game Design and Construction 2003, Science Direct Mehdi Dastani, Joris Hulstijn, leendert van der Torre, How to decide what to do? 2003, Science Direct GianCarlo Moschini, Nash Equilibrium in strictly competitive games: live play in soccer 2004, Science Direct Jacek Miekisz, Equilibrium selection in evolutionary games with random matching of players 2004, Science Direct Marko Sysi-Aho, Jari Saramaki, Kimmo Kaski, Invisible hand effect in an evolutionary minority game model 2004, Science Direct
R4 : CDs
[CD1]- Medal of Honor, Allied Assault, Electronic Arts [CD2]- Battlefield 1942 , Electronic Arts [CD3]- Star Wars Galactic Battleground, LucasArt Entertainment [CD4]- Caesar III, Sierra Entertainment [CD5]- Rainbow Six, Rogue Spear, RedOrb Entertainment [CD6]- Rise of Nation, Microsoft Games [CD7]- Age of Empires, Microsoft Games [CD8]- Sudden Strike, CDV Entertainment [CD9]- Codename Panzers Phase One
Appendices
Appendix A: Some famous quote from the leader of World War 2

"In spite of the hardness and ruthlessness I thought I saw in his face, I got the impression that here was a man who could be relied upon when he had given his word." Neville Chamberlain, British Prime Minister
"Yesterday, December 7, 1941- a date which will live in infamy- The United States was suddenly and deliberately attacked by naval and air forces of the Empire of Japan. .Always will our whole nation remember the character of the onslaught against us. No matter how long it may take us to overcome this premeditated invasion, the American people in their righteous might will win through to absolute victory." Franklin D. Roosevelt, December 8, 1941, In his speech of the attack on Pearl Harbor
"I'm afraid that we have just awaken a sleeping giant." Admiral Isoroku Yamamoto Mastermind of the attack on Pearl Harbor
"It is... the hope of all mankind that from this solemn occasion a better world shall emerge from the blood and carnage of the past." General Douglas Mac Arthur, In his speech during the signing of Japanese Surrender on board of USS Missouri.
"How calm, how peaceful it is A strip of water between England and Continent ... between the Allies and us. And beyond that peaceful horizon, a monster waits! A coil spring of mens, ships and planes... straining to be released against us. 231 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 But not a single Allied Soldier shall reach the shore. Whenever or wherever this invasion may come, Gentleman... I shall destroy the enemy there at water edge... The first 24 hours of the invasion will be decisive. For the Allies as well as the Germans, it will be the longest day... The longest day!" FeldMarshall Erwin Rommel In his speech on Normandy beaches
"Hitler knows that he will have to break us in this Island or lose the war, if we can stand up to him, all Europe may be free and the life of the world may move forward into broad, sunlit uplands. But if we fail, then the whole world, including the United States, including all that we have known and cared for, will sink into the abyss of a new dark age...Let us therefore brace ourselves to our duties, and so bear ourselves that, if the British Empire and the Commonwealth last for a thousand years, men will say: 'This was their finest hour.'" Winston Churchill British Prime Minister In his speech on the Battle of Britain
Appendix B: Personal Communication with Game Programmers

B.1: Game Programmers Contribution:
Below are the lists of programmers that are involved in the project. Their contribution to the project includes giving some advices, feedbacks, comments, and some programming code as well. David Brackeen: This game programmer has been involved in the game programming field for almost 15 years. His latest game project includes Race3D, a 3D racing game simulation, Scared3D, a first person action shooting game and some other simple games. All the games were entirely developed in Java. His has given some comments for this project about the features and drawbacks. Not only that, he has also given some guidance on what to develop for the game. He has also given some code fragments for the project such as online networking code. He has a personal websites, where the user can share his own opinion about their project and some list of Q and A section. Andre La Mothe: This contributor has been involved in the Game Programming field for almost 25 years. His is actively involved in NASA AI development project. His is the co founder of Extreme Games Incorporated. His has given some contributions to the project by giving some programming codes. These include Animation of Soldier, List of Weapons, and Enhanced Menus. He also gives some advice on how to develop a successful Game Project. David Wallace Croft: This person is the author of the famous book Advanced Java Game Programming. He has contributed in the project by giving some guidance on how to create a good Save and Load features. Andrew Rollings: This person has published the book titled Game Architecture and Design. He has give some idea of how to manage a game project by giving the architecture and principle behind a Game Project. This includes the resources needed, time management, and cost needed for the project.
David War Game Final Report Final Year Project 2004/05 Matthew Omernick: This person is the Graphics Designer working for EA Games (Electronic Arts Incorporated). His has written a book titled Creating the Art of the Game. He has contributed to the project by giving some ideas on how to created cool User Interfaces and effects for the game. Alex J. Champandard: This person writes the book titled AI Game Development. He has given some ideas about the AI needed for the enemy unit in the game, such as the enemy behavior, evolution programming, and morale of the troops. Daniel Sanchez: This person writes the book titled Core Techniques and Algorithms. He does not really contributed much to the project, but his book does give a good start for the project. David Freemon: This person is the author of the book titled creating emotion in games. His book gives a lot of idea and help for the project, but due to the complexity introduced in the project, his ideas has been dropped down anyway.
B.2: Game Programmers Contact Info:

David Brackeen: www.brackeen.com Andre La Mothe: ceo@xgames3d.com David Wallace Croft: Not available. Andrew Rollings: a.rollings@hiive.com Matthew Omernick: Not available. Alex J. Champandard: Not available. Daniel Sanchez: dsanchez@novarama.com David Freemon: david@freemangames.com
Appendix C: UI of the game developed

Below are few examples of the David War Game UIs:
Figure C1: Main Menu of David War Game
Figure C2: Choice of 2D and 3D Game of David War Game 236 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
Figure C3: 2D Menu (Version 1.2.1032)
Figure C4: 3D Menu (Version 1.2.1032)
Figure C5: Credit Menu (Version 1.2.1032)
Figure C6: About Menu (Version 1.2.1032)
Figure C7: Library Menu
Figure C8: Load Menu
Figure C9: Save Menu
Figure C10: 3D Game Choice Menu
Figure C11: Settings Menu
Figure C12: Loader Menu
Figure C13: Unit Editor Menu
Appendix D: Initial draft

Final Year Individual Dissertation Project Initial Draft/Proposal Title Group Name Group Members Supervisor War Games David War Games Name 1. Hong Jer Lang Mr. Nasreddine Hallam Student Card No. 495
Introduction: The Project name was chosen as War Games. Its about a game thats based on real war that has already happened long ago, namely World War 2. The main country that involved in the War, such as Germany, and America, will be the key player options in this project. User may choose the sides that they want, such as Germany, in order to play the game. However, only two sides of the country can only be present in the games one at a time, eg. No three or more countries can involve in the battle at the same time. Real historical event, such as the Battle of Stalingrad, Battle of Normandy, will be taken into account seriously when developing the scenery of the games. However, the games will be implemented in 2D only, due to the limitations of the Java Programming Languages. The units available, such as tanks, aircraft, etc. will also be implemented based on the real life examples. The program will be based on the real life historical event, as much as possible. Each unit will has it owns special ability, such as armor, firepower, speed, etc. There will also be buildings, tree, mountain, sea, and river available in the map editor, and some of these features will give some limitations to the unit involved. ( eg. Tank cant cross a river). The program of war games will also has some cheat codes available, such as enabling the invincibility of the units, super power, etc. Feature such as Save Games, Load Games, About, etc. will also be part of the War Games implementation. Music, an important feature in the war game, will be taken into consideration seriously for the game. Graphics, for sure, will be one of the most important parts in developing the game.
David War Game Final Report Final Year Project 2004/05 Each player will has his own HQ (Head Quarters), which functions as unit productions, and also the key goal for the game. Once the HQ is destroyed, the player will lose the game. Future work: 1. The map editor, where the user can create his own units, and own scenery, will be implemented at the final stage of the project. 2. Enhanced Map, such as 3D features, will be considered if possible. 3. Internet gaming, will also be implemented, if possible.
Area and Scope: The game will be distributed to the UNiM student and its freeware also. This game is developed such that the UNiM student can learn how to program his own game in the future. Its also targeted to the novice user who is keen to learn how to program a game using Java languages. Aim: To help novice users to learn how to program games using Java Programming Language. To enable user to enjoy themselves playing the game. To let user to appreciate the event of World War 2. Objectives: 1. To learn how to program a game using Java. 2. To learn the functions of the Open GL software. 3. To learn the rapid development phase. The program main UI and logic: 1. 2. 3. 4. It will probably consist of three main UI, The display of the opening of the game, the intro menu, and the game play menu. Open menu will display the progress of opening the game. Intro menu will have Load, Save, About, Scenario Editor, Start a Game Editor, just to name a few. 5. Game Play menu, will have the map of the game, with the players unit battling in it, and also some features for controlling the game.
David War Game Final Report Final Year Project 2004/05 Methodology: The methodology used will be a combination of SDLC and Rapid Prototyping. 1.Design -A design of the initial project structure. 1.Specifying the requirements of the project. 2.The structure of the project. (Data Flow Diagram) 2.Analysis -The outlook of the program, and the appropriate layout of the program. -A detail flow chart, DFD diagram, UML diagram, etc. 3.Development -The coding and designing of the program. 4.Implementation -Testing and debugging. -To make it into an executable application files. -Installer for the program -Changing the program from JVM code into native code. 5.Maintainance -Update and upgrade of the program over time. -Debugging the program after some initial feedback from users.
Software/Hardware: The program will be written explicitly in JAVA, principally on WinTel platforms. The final product will operate independent of OS layer and hardware. Details of some software: -Java Sun One Studio 1.4.1, a Java Program with a complete compiler. This will be used for the coding of the programming -JBuilder 9, a program with a complete compiler and some GUI design features. This will be used for the GUI design -JCreator 1.2.1, a fast program compiler that can compile and execute a Java files. This will be used just in case, for emergency purposes. -Microsoft Word 2000, a software that is used in preparing a report. -Microsoft PowerPoint, a software that is used in preparing a presentation slide. 245 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 -Microsoft Excel, a software to create the user requirements, estimation cost, etc -Netscape / Internet Explorer browsers which will be used to test the program on the web. -Internet Explorer. To find the resources for the program developed. -Microsoft Project, that will be used to plan the initial time planning of the program. -Paint, to create the icons of the unit available, such as tank. -Microsoft Photo Editor, to create and manipulate images. -Open GL, to create the 2D effect in the game. Any other Special needs: Other needs: -Some professional who can give advice/guidance to develop this project. -Others necessary stuff.
Appendix E: Map drawing by level

The display of Map created in David War Games (14 level). Level 1 is the default level.
Level 1
Figure E.1 Level 1 Map (Default Level)
Level 2
Figure E.2 Level 2 Map
Level 3
Level 4
Level 5
Level 6
Level 7
Level 8
Level 9
Level 10
Level 11
Level 12
Level 13
Level 14
Appendix F: Unit prototype drawing

This section gives the various view of the enemy unit created in the game. The game has 10 enemy units: 1. Tiger 1 Heavy Tank 2. Jagd Panther Tank Destroyer 3. Half Track Ammo Truck 4. 88 Anti Tank Gun 5. M4 Sherman Medium Tank 6. T34 Medium Tank 7. Infantry Unit 8. Bazooka Team 9. ZTekken Secret Tank 10. Bunker
F1: Individual Unit Capability:

Tiger 1 Tank
Figure F1.1 Tiger 1 Unit Speed : **** Armor : ***** Firepower : ***** AI : **** Braveness : ***** Visibility : *** (All tank have poor visibility, like in the real life!!) Size : *****
Jagd Panther Tank Destroyer
Figure F1.2 JagdPanther Unit Speed : *** Armor : ***** Firepower : ***** AI : ** Braveness : ***** Visibility : ** Size : *****
David War Game Final Report Final Year Project 2004/05 Half Track
Figure F1.3 Half Track Unit Speed : ***** Armor : *** Firepower : *** AI : **** Braveness : *** Visibility : **** Size : ***
David War Game Final Report Final Year Project 2004/05 88 Anti Tank Gun
Figure F1.4 88 Anti Tank Unit Speed : * Armor : *** Firepower : ***** AI : ** Braveness : ***** Visibility : *** Size : **
David War Game Final Report Final Year Project 2004/05 Sherman Tank
Figure F1.5 Sherman Unit Speed : **** Armor : *** Firepower : *** AI : **** Braveness : **** Visibility : *** Size : ***
David War Game Final Report Final Year Project 2004/05 T34 Tank
Figure F1.6 T34 Unit Speed : **** Armor : *** Firepower : *** AI : **** Braveness : **** Visibility : *** Size : ***
David War Game Final Report Final Year Project 2004/05 Infantry Unit
Figure F1.7 Infantry Unit Speed : **** Armor : * Firepower : * AI : ***** Braveness : *** (Depending on each individual unit) Visibility : ***** Size : *
David War Game Final Report Final Year Project 2004/05 Bazooka Unit
Figure F1.8 Bazooka Unit Speed : **** Armor : * Firepower : *** AI : ***** Braveness : *** (Depending on each individual unit) Visibility : ***** Size : *
David War Game Final Report Final Year Project 2004/05 Indestructible Bunker Unit
Figure F1.9 Bunker Unit Speed : * Armor : ***** Firepower : ***** AI : *** Braveness : ***** Visibility : * Size : *****
David War Game Final Report Final Year Project 2004/05 Z Tekken Tank
Figure F1.10 ZTekken Unit Speed : ***** Armor : ***** Firepower : ***** AI : ***** Braveness : ***** Visibility : ***** Size : *
F2: The Prototype Drawing of Enemy Unit:
TIGER 1 3D
Figure F2.1.1 Tiger 1 3D View
TIGER 1 TOP VIEW
Figure F2.1.2 Tiger 1 Top View
TIGER 1 FRONT VIEW
Figure F2.1.3 Tiger 1 Front View
TIGER 1 BACK VIEW
Figure F2.1.4 Tiger 1 Back View
TIGER 1 SIDE VIEW
Figure F2.1.5 Tiger 1 Side View
JAGDPANTHER 3D
Figure F2.2.1 JagdPanther 3D View
JAGDPANTHER TOP VIEW
Figure F2.2.2 JagdPanther Top View
JAGDPANTHER FRONT VIEW
Figure F2.2.3 JagdPanther Front View
JAGDPANTHER BACK VIEW
Figure F2.2.4 JagdPanther Back View
JAGDPANTHER SIDE VIEW
Figure F2.2.5 JagdPanther Side View
HALF TRACK 3D
Figure F2.3.1 Half Track 3D View
HALF TRACK TOP VIEW
Figure F2.3.2 Half Track Top View
HALF TRACK FRONT VIEW
Figure F2.3.3 Half Track Front View
HALF TRACK BACK VIEW
Figure F2.3.4 Half Track Back View
HALF TRACK SIDE VIEW
Figure F2.3.5 Half Track Side View
88 MM 3D
Figure F2.4.1 88 3D View
88 MM TOP VIEW
Figure F2.4.2 88 Top View
88 MM FRONT VIEW
Figure F2.4.3 88 Front View
88 MM BACK VIEW
Figure F2.4.4 88 Back View
88 MM SIDE VIEW
Figure F2.4.5 88 Side View
M4 SHERMAN 3D
Figure F2.5.1 Sherman 3D View
M4 SHERMAN TOP VIEW
Figure F2.5.2 Sherman Top View
M4 SHERMAN FRONT VIEW
Figure F2.5.3 Sherman Front View
M4 SHERMAN BACK VIEW
Figure F2.5.4 Sherman Back View
M4 SHERMAN SIDE VIEW
Figure F2.5.5 Sherman Side View
T34 3D
Figure F2.6.1 T34 3D View
T34 TOP VIEW
Figure F2.6.2 T34 Top View
T34 FRONT VIEW
Figure F2.6.3 T34 Front View
T34 BACK VIEW
Figure F2.6.4 T34 Back View
T34 SIDE VIEW
Figure F2.6.5 T34 Side View
INFANTRY 3D
Figure F2.7.1 Infantry 3D View
INFANTRY TOP VIEW
Figure F2.7.2 Infantry Top View
INFANTRY FRONT VIEW
Figure F2.7.3 Infantry Front View
INFANTRY BACK VIEW
Figure F2.7.4 Infantry Back View
INFANTRY SIDE VIEW
Figure F2.7.5 Infantry Side View
BAZOOKA 3D
Figure F2.8.1 Bazooka 3D View
BAZOOKA TOP VIEW
Figure F2.8.2 Bazooka Top View
BAZOOKA FRONT VIEW
Figure F2.8.3 Bazooka Front View
BAZOOKA BACK VIEW
Figure F2.8.4 Bazooka Back View
BAZOOKA SIDE VIEW
Figure F2.8.5 Bazooka Side View
BUNKER 3D
Figure F2.9.1 Bunker 3D View
BUNKER TOP VIEW
Figure F2.9.2 Bunker Top View
BUNKER FRONT VIEW
Figure F2.9.3 Bunker Front View
BUNKER BACK VIEW
Figure F2.9.4 Bunker Back View
BUNKER SIDE VIEW
Figure F2.9.5 Bunker Side View
ZTEKKEN 3D
Figure F2.10.1 ZTekken 3D View
ZTEKKEN TOP VIEW
Figure F2.10.2 ZTekken Top View
ZTEKKEN FRONT VIEW
Figure F2.10.3 ZTekken Front View
ZTEKKEN BACK VIEW
Figure F2.10.4 ZTekken Back View
ZTEKKEN SIDE VIEW
Figure F2.10.5 ZTekken Side View
Sturm Tiger 3D View
Figure F2.11.1 Sturm Tiger 3D View
Sturm Tiger Top View
Figure F2.11.2 Sturm Tiger Top View 291 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
Sturm Tiger Front View
Figure F2.11.3 Sturm Tiger Front View
Sturm Tiger Back View
Figure F2.11.4 Sturm Tiger Back View
Sturm Tiger Side View
Figure F2.11.5 Sturm Tiger Side View
Panther 3D View
Figure F2.12.1 Panther 3D View
Panther Top View
Figure F2.12.2 Panther Top View
Panther Front View
Figure F2.12.3 Panther Front View
Panther Back View
Figure F2.12.4 Panther Back View
Panther Side View
Figure F2.12.5 Panther Side View
JS2 3D View
Figure F2.13.1 JS2 3D View
JS2 Top View
Figure F2.13.2 JS2 Top View
JS2 Front View
Figure F2.13.3 JS2 Front View
JS2 Back View
Figure F2.13.4 JS2 Back View
JS2 Side View
Figure F2.13.5 JS2 Side View
Willy 3D View
Figure F2.14.1 Willy 3D View
Willy Top View
Figure F2.14.2 Willy Top View
Willy Front View
Figure F2.14.3 Willy Front View
Willy Back View
Figure F2.14.4 Willy Back View
Willy Side View
Figure F2.14.5 Willy Side View
Appendix G: Weapons In David War Game

Weapon 1: Handgun:
Figure G.1: Heckler & Koch P9 Reliability: *** Accuracy: ** Age: **** Worldwide Users: *** Range: * Specification Cartridge: 9mm Weight: 0.80kg Length: 180mm Cyclic rate of fire: 25 rounds per minute Magazine: 12 Description: This handgun is the standard weapon used by the German Infantry and officers. Its simplicity in design and usability made it a formidable weapon in World War 2. It could load up to 12 magazines in a round. It could be describe as one of the best handgun in World War 2.
David War Game Final Report Final Year Project 2004/05 Weapon 2: Rifle:
Figure G.2: KAR 98 Rifle Reliability: **** Accuracy: ***** Age: **** Worldwide Users: **** Range: **** Specification Cartridge: 7.32mm Weight: 2.30kg Length: 850mm Cyclic rate of fire: 18 rounds per minute Magazine: 1 Description: This rifle id the most common weapon used in the infantry. However, it still lacks of firepower and reloading time compared to the US M1 Garand Rifle. It could be converted to Sniper Rifle based on its design. This weapon has been commonly used in Russia as well as the European Front.
David War Game Final Report Final Year Project 2004/05 Weapon 3: Sub Machine Gun:
Figure G.3: MP40 Sub Machine Gun Reliability: **** Accuracy: *** Age: **** Worldwide Users: **** Range: *** Specification Cartridge: 7.92mm Weight: 3.05kg Length: 750mm Cyclic rate of fire: 650 rounds per minute Magazine: 32 Description: This weapon is one of the best sub machine gun in World War 2. Its magazine of 32 rounds gives the weapon a considerable power when used against the infantry. Not only that, it has quite good firepower and range too. This weapon has been adopted as the standard weapon for the sub machine gunner. It has also been widely used in the German Submarine. The German has also announced that the SS Commando Unit used this weapon as part of its exercise.
David War Game Final Report Final Year Project 2004/05 Weapon 4: Machine Gun:
Figure G.4: MP 44 Machine Gun (Assault Rifle) Reliability: **** Accuracy: **** Age: **** Worldwide Users: **** Range: **** Specification Cartridge: 7.62mm Weight: 4.05kg Length: 1050mm Cyclic rate of fire: 750 rounds per minute Magazine: 32 Description: This weapon is the best assault rifle in World War 2. Comparable to the US 7.62mm Caliber and the British Browning Machine Gun, it has more firepower and range. Not only that, its recoil capability is better than any comparable World War 2 weapon. This weapon has been adopted as the future design of Assault Rifle. It is being used by the German Commando SS unit and the Paratroopers as well.
David War Game Final Report Final Year Project 2004/05 Weapon 5: Heavy Machine Gun:
Figure G.5: MG42 Heavy Machine Gun Reliability: **** Accuracy: ***** Age: **** Worldwide Users: **** Range: ***** Specification Cartridge: 7.62mm Weight: 6.20kg Length: 1350mm Cyclic rate of fire: 1050 rounds per minute Magazine: 40 Description: This weapon can be considered as one of the best Heavy Machine Gun in World War 2. It can be fitted to any German Tank Unit. It has a great amount of ammo storage. However, it requires a great amount of skills to handle this weapon. This weapon serves as a potent weapon during the Battle of Normandy. It is an improved version compared to the MG34 Light Machine Gun.
Weapon 6: Sand Grenade:
Figure G.6: Sand Grenade Reliability: **** Accuracy: *** Age: **** Worldwide Users: *** Range: *** Specification Cartridge: NA Weight: 2.50kg Length: 400mm Cyclic rate of fire: NA Magazine: NA Description: This weapon is the standard weapon used by the German Assault troops. It is widely used for Anti Tank purposes. The damage done by this weapon is above average. It can cause considerably amount of damage to the vehicle, if it was used correctly. It also serves as an alternative to the hand grenade, except that it has more damage compared to the latter.
Weapon 7: Mine:
Figure G.7: Land/Anti Tank Mine Reliability: *** Accuracy: ** Age: **** Worldwide Users: *** Range: * Specification Cartridge: NA Weight: 2.80kg Length: 250mm Cyclic rate of fire: NA Magazine: NA Description: This weapon has been greatly used by the German at the Normandy beaches. The Germans has planted more than a million mines at the coast of France, particularly Calais. This weapon serves as the Anti Tank weapon. An alternative version for the infantry has also been developed as well.
Weapon 8: Time Bomb:
Figure G.8 Time Bomb (10 seconds activation) Reliability: *** Accuracy: ***** Age: **** Worldwide Users: **** Range: *** Specification Cartridge: NA Weight: 2.60kg Length: 260mm Cyclic rate of fire: NA Magazine: NA Description: This weapon is widely used by the Assault Infantry and German Commando Units. It serves to destroy buildings, besides the tanks as well. During the advanced of the Allies in 1944, the German has used considerably amount of this weapon in destroying the bridges.
Weapon 9: Bazooka (Panzerfaust):
Figure G.9 Bazooka (Panzerfaust) Reliability: ***** Accuracy: ***** Age: **** Worldwide Users: **** Range: ***** Specification Cartridge: NA Weight: 5.50kg Length: 1300mm Cyclic rate of fire: NA Magazine: NA Description: This weapon is the standard weapon used by the German Anti Tank Unit, better known as Panzerfaust. The American used the M1 Bazooka, while the British has the PIAT team as its Anti Tank Unit. This weapon is known as one of the most potent weapon for Anti Tank purposes.
Appendix H: Time Management
Figure H1: The Time Management for David War Game with the Gantt chart displayed. The project is expected to start at beginning of June 2004 and end at end of April 2005.
Appendix I: Questionnaire and its analysis

I.1 Questionnaire of David War Game:
David War Games Questionnaire *Name: *Course: *Year: 1. Have you ever played any war games (PC) before? -Yes -No
2. What is your favourite PC War Games? __________________________________________________________________ 3. What kind of War Games have you played? Tick the necessary one. Real time strategy First Person Shooter Third Person Shooter RPG (Role Playing Game) Adventure Platform Others, if applicable
4. What unit do you really want in War Games? Tick the necessary one. Tanks Ships Submarines Aircrafts Soldiers Super weapons Others units such as _________________________________________ None of the above should be in the game
5. What kind of buildings do you think should be in a game? Tick the necessary one. Houses Head Quarters
David War Game Final Report Final Year Project 2004/05 War Factory Barracks Air Field Bridges Oil Depot Military Academy Fortress Others buildings such as _____________________________________ None of the above should be in the game
6. Did you think diplomacy is a must in a game? Such as forming an alliance with other players. -Yes -No -No idea
7. Do you really think Internet Gaming would be an appropriate option in developing a game? -Yes -No -No idea
8. Did you think a game with map editor would be better than others? Such as in Real Time Strategy Games. -Yes -No -No idea
9. What other new features would you like to have in a game? __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________
10. What type of features do you think are important when developing a game? __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ Optional: 312 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 Do you want a version of David War Games when it has been released? -Yes -No
* All the applicants information will be kept confidential. Thank you for your cooperation.
I.2 Analysis of David War Game Questionnaire: Analysis Of The David War Games Questionnaire
Introduction: This questionnaire has been given to a set of 15 students, all of them CSiT students who studied in University of Nottingham in Malaysia and a good user in playing some War Game in PC. Surprisingly, only guys were chosen to be given this questionnaire due to the fact that most guys love to play War Games, while only few of the girls who really love to play War Games. Thus, this Questionnaire would look a little bit bias, in terms of the set of applicants. On the other hand, none of the Business and Engineering Students has been chosen to be given this questionnaire due to their lack of knowledge about PC, which would affect the results of this questionnaire indirectly. It is assumed that no foul play given by the applicants when answering this questionnaire. In other word, the answer given by the applicants would be an honest and sincere one.
Analysis of question, sorted by questions number: 1. Have you ever played any war games (PC) before?
Question 1
Yes No
15
Summary: All the applicants answered that they have played War Games before, which shows that the questionnaire was given to qualify applicants, thats an applicant that has a very deep knowledge about War Games. 2. What is your favourite PC War Games? War Craft - 4 Star Craft - 3 Command and Conquer - 2 Counter Strike - 1 Battle Grounds 2 - 1 Three Kingdoms - 1 Age of Empires - 1 Total Annihilation - 1 Ragnarok - 1 Battlefield 1942 - 1 Note: 2 applicants gives two favorite games, while one applicant gives none. Summary: War Craft games seems to be on the leading, with a frequency of 4, which shows that many Game Players in this society love to play this game. Even though it has been quite long in the market, it is still remain as the favourite game for the game community, based on this statistic. Star Craft, which was slightly behind, was the game players second choice. It can be seen from the statistic that most players prefer a RTS (Real Time Strategy) or a FPS (First Person Shooter) type of game. However, those games that were the choice of the game players were a little bit too old (outdated) and most of them were based on the Future War and Science Fiction, with Historical War being on the minority. In general, those popular games like Diablo 2, Baldur Gate, Sudden Strike, and Medal of Honor 314 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 were seemed not to be the favourite of the game players, which is something strange and uncommon. 3. What kind of War Games have you played? Tick the necessary one. Real time strategy First Person Shooter Third Person Shooter RPG (Role Playing Game) Adventure Platform Others, if applicable
Question 3
RTS 12 FPS TPS RPG
10 5 10
Adv Platform Others
Summary: Most people prefer to play Real Time Strategy games, followed by First Person Shooter, and Role Playing Game, with both of them having the same frequencies. However, one of them has plays SGL, which is something rare in gaming field. This statistic shows that most players prefer Real Time Strategy as their favourite game, supporting the fact in the Question 2.
4. What unit do you really want in War Games? Tick the necessary one. Tanks Ships Submarines Aircrafts Soldiers Super weapons
David War Game Final Report Final Year Project 2004/05 Others units such as _________________________________________ None of the above should be in the game
Question 4
Tank 2 10 6 1 8 Ship Sub Aircraft Soldier 6 10 4 SuperW Other None
Summary: Most players prefer to have the Super Weapons in the game, indicating that a game would be better if it has Super Weapons developed in it. Players also prefer to have Aircraft in the game, due to the fact of the popularity of the Aircraft in most commercial game, and the capability that an aircraft could have given in a War Game. Tank, would follow the list of the players choice, due to the fact that most commercial game has implemented tank in their game and it also serves as the most important and interesting features in the game developed. Those units that are of necessity in a War Game seem to have a high frequency, in general. This shows that the players want most of the choices of units to be in the War Games. However, one applicant answered that none of the units should be in the game. 5. What kind of buildings do you think should be in a game? Tick the necessary one. Houses Head Quarters War Factory Barracks Air Field Bridges Oil Depot Military Academy Fortress Others buildings such as _____________________________________ None of the above should be in the game
Question 5
House 2 7 10 0 6 9 HQ War Fact Barrack Air Field Bridges 5 5 10 11 12 Oil Depot Mil Aca Fortress Others None
Summary: Most applicants want War Factory to be in the game, due to the fact that these buildings can generate units, and determine the success of the particular mission, thus making it the most important buildings in the game. Barrack, Air Field and military academy, which are also the players choice, are also an important building, and these buildings as well, like the War Factory, can produce weapon, soldier, planes and war equipment, which indirectly determine a nation military might and superiority compare to other nations. In general, those buildings that can determine the strength of a military might of a particular nation, like War Factory, are prefer by the players rather than the one that are not, like houses.
David War Game Final Report Final Year Project 2004/05 6. Did you think diplomacy is a must in a game? Such as forming an alliance with other players.
Question 6
2 6 Yes No No idea 7
Summary: The players who chose Yes and No are almost same in terms of frequency, with a difference of one. Two applicants answered no idea, due to the fact of lack of experience in playing a game with Diplomacy styles. However, applicants who say No has higher frequency than the rest, giving a conclusion that a player victory in the game would be based on his intelligent and skills, not diplomacy.
David War Game Final Report Final Year Project 2004/05 7. Do you really think Internet Gaming would be an appropriate option in developing a game?
Question 7
1 Yes No No idea 13
Summary: Most of the applicants answered Yes, due to the fact that Internet Gaming has been very popular nowadays, with its widespread in the gaming society. In fact, Internet has been so popular that most of the young generations have been exposed to it, particularly those Game Players who like to play a Game in the Cyber Cafe. However, one applicant answered no idea.
David War Game Final Report Final Year Project 2004/05 8. Did you think a game with map editor would be better than others? Such as in Real Time Strategy Games.
Question 8
0 7 8 Yes No No idea
Summary: The applicants who answered Yes or No seem to be partitioned into two groups, with a difference of one only. This shows that some would prefer Map Editor to be implemented in a game, while others think that it is just a waste of time and effort to have it in a game.
David War Game Final Report Final Year Project 2004/05 9. What other new features would you like to have in a game? -Real time strategy added with role playing features -Better in 3D -Gives an interface or API for the user to add in their part -Better interactivity and communication between players -Better AI, computer has much better strategy -A grace period for setup Summary: Most applicants give good idea, while some others have no idea at all. 10. What type of features do you think are important when developing a game? -Interactivity and online -Usability, learn ability, and guessable -Performance and graphics, low resource requirement -Super graphics -Good game play -Plot -Ergonomic features, good AI -Efficient graphics handling -Unlimited saving for check points -Storyboard Summary: This question was answered more than the previous one, due to the fact that its more general and easier to understand. However, some applicants still leave this question unanswered.
Optional: Do you want a version of David War Games when it has been released?
Optional
2 Yes No 13
Summary: Most applicants want a copy of the David War Games, while minority of them answered No. No conclusion can be drawn from this question, as its too abstract in structure.
Appendix J: Description of Unit In Real World

Tiger 1
Figure K.1 Tiger 1 Tank Description: Country: Germany Main Armament: One 88mm (3.5in) KwK 36 cannon Secondary Armament: Two 7.92mm (0.3in) MG34 machine guns Combine Weight: 56 tons Length: 8.26m Width: 2.82m Height: 2.86m Road Speed: 37km/h Road Range: 117km Crew: 5
JagdPanther
Figure K.2 JagdPanther Tank Destroyer Description: Country: Germany Main Armament: One 88mm (3.5in) PaK 43/4 cannon Secondary Armament: One 7.92mm (0.3in) MG34 Machine Gun Combine Weight: 46 tons Length: 9.9m Width: 3.42m Height: 2.72m Road Speed: 46km/h Road Range: 160km Crew: 5
HalfTrack
Figure K.3 Sdfkz 121 Armored Personal Carrier Description: Country: Germany Main Armament: NA Secondary Armament: One 7.92 (0.3in) MG34 Machine Gun Combine Weight: 7.5 tons Length: 7.5m Width: 1.95m Height: 2.0m Road Speed: 85km/h Road Range: 300km Crew: 4
88 Anti Tank Gun
Figure K.4 88mm Anti Tank Gun Description: Country: Germany Main Armament: One 88mm PAK 72 Secondary Armament: NA Combine Weight: 8 tons Length: 7.0m Width: 2.2m Height: 2.8m Road Speed: NA Road Range: NA Crew: 5
Sherman
Figure K.5 M4A3 Sherman Medium Tank Description: Country: USA Main Armament: One 75mm (3in) cannon Secondary Armament: None Combine Weight: 31.1 tons Length: 7.53m Width: 2.69m Height: 2.74m Road Speed: 40km/h Road Range: 240km Crew: 5
T34
Figure K.6 T34 Medium Tank Description: Country: Soviet Union Main Armament: One 76.2mm (3in) F34 cannon Secondary Armament: Two 7.62mm (0.3in) DT machine guns Combine Weight: 30 tons Length: 5.92m Width: 3m Height: 2.45m Road Speed: 55km/h Road Range: 300km Crew: 4
Infantry
Figure K.7 German Infantry Unit Description: Country: Germany Main Armament: One KAR 98 Rifle Secondary Armament: Sand Grenade, Mine Combine Weight: 65kg Length: 15cm Height: 182cm Road Speed: NA Road Range: NA Crew: 1
Bazooka Team
Figure K.8 German Bazooka Unit (Panzerfaust) Description: Country: Germany Main Armament: One Panzerfaust Anti Tank Gun Secondary Armament: Sand Grenade, Mine Combine Weight: 65kg Length: 15cm Height: 182cm Road Speed: NA Road Range: NA Crew: 1
Sturm Tiger Assault Mortar
Description: Country: Germany Main Armament: One 152mm Assault Mortar Secondary Armament: None Combine Weight: 80 tons Length: 5.5cm Height: 2.9cm Road Speed: 35 km/h Road Range: 200km Crew: 5
Panther
Description: Country: Germany Main Armament: One 75mm Kwk PAK 57 Secondary Armament: Two 7.92 mm machine gun Combine Weight: 65 tons Length: 6.2cm Height: 2.75cm Road Speed: 65 km/h Road Range: 450km Crew: 5
JS2
Description: Country: Soviet Union Main Armament: One 122mm Gun Secondary Armament: One 7.62 mm machine gun Combine Weight: 78 tons Length: 6.5cm Height: 2.45cm Road Speed: 63 km/h Road Range: 450km Crew: 4
Willy
Description: Country: US Main Armament: One 7.62mm machine gun Secondary Armament: None Combine Weight: 5 tons Length: 2.5cm Height: 1.3cm Road Speed: 72 km/h Road Range: 650km Crew: 5
Appendix K: David War Game User Manual
Table of Content Content Page
Introduction and overview ............................................................................................. 337 Installation ..................................................................................................................... 338 General Game Commands............................................................................................. 339 Settings ........................................................................................................................... 340 Secret Levels in 2D Game.............................................................................................. 340 Special Features............................................................................................................. 340 Hints On How To Play The 3D Game........................................................................... 341 How to Play The 3D Game ............................................................................................ 342
Introduction and overview

David War Game has two components in it, the 2D Game, and the 3D Game. 2D Game will be based on the Adventure Styles Game Concept, while the 3D Game will be based on the First Person Shooter Game Concept. The story line of this game has been written based on the story of World War II. The Game has minimum efficiency, realism and game play compared to the available Commercial Game. However, the game has much better functionality and usability compared to the commercial games. In fact, the game has been equipped with Evolution Concept for its AI (Artificial Intelligence) Capability. Besides that, the game is the first First Person Shooter Game to have a Unit Editor in it. It is also the first game that incorporates 2D and 3D game as part of its system. Not only that, it has a very detailed and flexible Library Menu. (This library menu has animation and lots of interactivity with the enemy units). The programmer of this system hopes that the users will enjoys the game while gaining some knowledge on the World War II.
Installation
Requirements specification The game needs the following requirements in order for full running: 1. 2. 3. 4. CPU speed of 2.4Ghz or better. A RAM amount of 512MB, preferably with 1024MB of RAM memory. A hard disk amount of 120MB. (Preferably with 150MB). A graphics memory of 16MB (Preferably a 32MB dedicated graphics memory, such as ATI Radeon or NVIDIA GeForce). 5. Supported sound card. 6. Java 1.4.2 SDK or higher. 7. Windows XP Home Edition or Windows XP Professional Edition. (The system has been created and can only be deployed in Wintel Platform only). Installation Instruction The CD will give auto install upon reading by the CD drive. If this does not work, click on the Installer in the CD. You must open and explore the CD first before finding the Installer. Follow the instruction in the Installer for successful installation. License Due to the copyright issues and deployment limitation, this software will only be available for the period of only 90 days. After 90 days, the software will not run. The users must seek the permission of the developer for a full version.
General Game Commands

The 2D Game comes with the following keyboard commands:
Left: Go left. Right: Go right. Space bar: Jump. Escape: Exit the game. P: Pause the game.
The 3D Game comes with the following commands:

Mouse: Left Click: Fire/Plant Device Right Click: Zoom Keyboard: P: Pause the Game. Escape: To the menu. Space bar: Jump Left/A: Look left. Right/D: Look right. Up/W: Go forward. Down/S: Go backward. Plus: Zoom In. Minus: Zoom Out. 1: Select Hand Gun. 2: Select Rifle. 3: Select Sub Machine Gun. 4: Select Machine Gun. 5: Select Heavy Machine Gun. 6: Select Sand Grenade. 7: Select Mine. 8: Select Time Bomb. 9: Select Bazooka. Shift: Toggle Run Mode O: Reload weapon M: Map Display
Settings
The settings panel allows the user to configure the audio options, keyboard mapping, mouse mapping, difficulty level, as well as enables the cheat codes. Note that the keyboard and mouse mapping has been set to default due to a serious unfixed bug in the system. The programmer has tried his best to solve this problem, but manages to solve it up to 95%, and due to the time constraint, he decided to set the mapping to default value.
Secret Levels in 2D Game

There is a secret level created in the 2D Game. The user has to explore it himself in order to know what it is. However, there are no credits given to the player who manages to unveil the secret level.
Special Features
The Game has been equipped with Unit Editor, which is unavailable in the commercial games at the moment. The programmer is proud to announce this new feature as part of the system capability. The Unit Editor enables the player to create his own enemy units based on the criteria set up by him. The Game also has a complicate and advanced Library Menu, which is also unavailable in the commercial games. This enhanced library menu has flexible navigation of enemy unit, animation of weapons and 3D enemy units viewing. Finally, the system has plug in feature as part of its implementation. However, most commercial games have this feature as well. The plug in feature enables the player to create his own map and play it in the system. (He must load the map first before playing it).
Hints On How To Play The 3D Game

Below are some hints on how to play the 3D Game: 1. The goal for every 3D Game is to destroy every single enemy units, so the player must search for every enemy units before he could win the game. 2. Do not used infantry weapons when you encountered a vehicle, such as tanks. Not only that you waste your ammo, but it is ineffective against it. Enemy vehicle, such as tanks, are not vulnerable to infantry weapons. 3. Try to use time bomb if you encountered a bunker. Time bomb has the highest damage point compared to other weapons. Therefore, it is very effective against a heavily armored unit such as the bunkers. 4. Use sand grenade only for static enemy units. (Like the 88s and Bunkers). Sand grenades are effective against static object, and it has good spreading power. (When it explodes on a ground, its damage can be spread to the surrounding). 5. Use Bazooka only when you have good aiming capability. Bazooka is effective only when it was aim correctly at the enemy. Therefore, it can easily kill a static enemy than a non static enemy. 6. Use Rifle only when you are sure to hit the enemy. Rifle gives high damages on the enemy unit, but it has a relatively slow loading time compared to other weapons. Besides that, it has only 6 rounds of ammunition in a magazine. 7. Do not waste your ammunition on unnecessary target. It is important to save your ammo especially when you play a brutal stage difficulty. Whenever a player runs out of ammo, he has more chances to lose rather than winning the game. 8. Use your heavy machine gun wisely. Heavy Machine Gun is the most effective weapon against the infantry units. Therefore, careful usage of this weapon is a must to gain absolute victory. 9. Hide somewhere when reloading your weapon. It is important to hide at a secure place when reloading your weapon as this reduces the enemy chance to see and hit you. 10. Try to charge against the enemy units when needed. If you are really short of ammo, the best way to win the game is to fight bravely by going towards the enemy units. (The enemy unit was designed to change its pattern from aggressive to scared when confronted suddenly by a player). 11. Plant the mine close to the enemy units. Not only do this tactic gives higher chances for the enemy units to step on it, but it makes the enemy unit to become low in morale when a daring tactic was used against it. 12. Use time bomb if there are too many enemy units. When enemy units come in group, their morale will be extremely high. They will fight bravely against you. Therefore the best way to handle this situation is to use the time bomb which could easily kill all of them.
How to Play The 3D Game
Info Update
Ammunition Bar
Player Status
Health Bar
Weapon Display
Figure 1 The 3D Game. General Rules 1. 2. 3. 4. 5. The user needs to use the walk key to move through the map. User will click the mouse left button when he wanted to fire at the enemy. A user can see his health status by looking at the health bar. He can also see the players status by looking at the Player Status Panel. A user can knows which type of weapon he is using at the moment by looking at the Weapon Display Panel. 6. Ammunition Bar will give the amount of ammo left on the weapon. 7. The total amount of ammo will be depicted by number at the weapon display. In the figure the amount was 300. 8. Info update will give the spawn, object and environment update for the player.
David War Game Final Report Final Year Project 2004/05 Some important rules when playing the game 1. Hide somewhere when reloading a weapon. 2. Used appropriate weapon when confront by an enemy. (For infantry, it is advisable to use the Heavy Machine Gun, while for tank it is advisable to use the mine or sand grenade). 3. Avoid using weapon that has little ammo remaining. 4. Used weapon that has great damages upon activation. (Like the time bomb).
Appendix L: Beta Testing Analysis David War Game Beta Test Evaluation Form
Name: Age: Gender: Bugs Occurrence: Description Bugs
Issues Raised: Description Issues
David War Game Final Report Final Year Project 2004/05 Some feedback on the game: 1. How would you rate the game? -Very Poor -Poor -Moderate -Good -Very good
2. How stable is the game? -Very Poor -Poor -Moderate -Good -Very good
3. How do you think of realism aspect of the game? -Very Poor -Poor -Moderate -Good -Very good
4. Does the game contain many features? -Yes -No
5. Does the game look like the commercial games? -Yes -No
The developer of David War Game would like to say many thanks to the beta user of the system and wish that they would enjoy the game. * All applicants data will be kept confidential
Analysis of the Beta Testing

Semester 1: In the first semester, the beta users will be selected from the University Students. It will consist of 6 students, all from the CS&iT department, and are expected to have a good knowledge about War Game. Most of the users gave good feedback and analysis, with an exception of few who gave very good response, and some who did not give any comment at all. Below are some of their feedbacks: 1. The memory consumption of the system. Most of the users complained about the system incapability to handle memory efficiently. The system seems to suffer from insufficient memory usage. Anyway, this problem seems to be a big issue and is not easy to solve in the first place. 2. The lack of functionalities in the 2D Game. The player in 2D game does not have life icon, and there is no goal state defined in the 2D Game. 3. Slow loading time of the menu. 345 By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM
David War Game Final Report Final Year Project 2004/05 Some menus, particularly the Library Menu, seem to suffer from a long loading time. 4. Lack of features in the 3D Game. The 3D Game does not have many mission, and lack of weapon choices for the player. 5. Some small and easy to fix bugs. The entire user manages to find many small and obvious bugs in the system. These bugs will be fixed in the new version of the War Game. Semester 2: During the second semester, the second phase of Beta Testing is being carried out. This time, the users are selected from all kinds of background, and are selected randomly. The users for the second beta testing gave better feedback than the user in the first phase of the beta testing, due to the fact that they are more knowledgeable in War Game. Below are some of their feedbacks: 1. Memory consumption of the system. Like in the first semester, the user of the beta test complained about this limitation again. This problem however, manages to be solved for about 85% and will be tested again in the third phase of the beta testing. The developer of the system needs to have enough time to fix this bugs as this bugs is a major one and not easy to fix in the first place. 2. Some small and easy to fix bugs. A lot of small and obvious bugs has been given during the beta testing. However, this number of these bugs is far smaller than the one in the first phase. These bugs will be fixed and the system will be tested again in the third phase. Feedback about the game: Most users think that the game is not good enough compared to the commercial one. However, the users also commented that the game has quite good realism based on the World War 2 story. They also agreed that the game being developed is a complex one and the system has more functionalities than those commercial one. Finally, most of the beta users suggest that more effort need to be done to upgrade the system in the future, knowing that the time of completion of the system is limited. Conclusion: There will be no third phase of the beta testing anymore. The system needs to be deployed by the end of the semester. There is not enough time to do another beta test again. In short, the system will be deployed to the users after the completion of the second phase of the beta test.

Jer Lang

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jer Lang

Uploaded by

Copyright:

Available Formats

Division of Computer Science and Information Technology University Of Nottingham, Malaysia Campus

UG FINAL YEAR DISSERTATION REPORT

- David War Game -

- David War Game -

Signature ________________________ Date 04/05/2005

UG FINAL YEAR DISSERTATION FINAL REPORT

Title: David War Game Version: X11 Beta 2

David War Game Final Report Final Year Project 2004/05

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

Part II: Analysis and Design

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

3.2 : UML As A Modeling Tool For The Proposed System

3.3 : Requirement Specification

3.4 : Some sample UI of the proposed System

3.5 : Design Choices for David War Game

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

Part III: Implementation

103 104 105

Chapter 5: 2D Game Design

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

Chapter 6: Graphics and Environment in 3D Game

116 116 117 120 120 121 121

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

: AI For The Unit in 3D Game

185 185 186 187 187 188

Chapter 8: Other Features in 3D Game

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

Part IV: Testing, Problems, and Planning

Chapter 10: Future work and planning

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

80 86 106 115 170

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

Chapter 1 Introduction and overview

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

1.2 Historical Background

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

Motivation for the Project

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM

David War Game Final Report Final Year Project 2004/05

By David Hong Jer Lang Computer Science Year 3 CS&iT UNiM