Java Webstart is really easy to use. It allows the customers to install a game very easily. You only need one click (or a very limited number of click) to be able to play. The image below shows what happens when you launch the game :
If it works fine, at the end of the download, you will see this :
The loading may last at most 20 seconds, it depends on your computer speed. After the loading, you will see this :
Now, there are some enemies trying to shoot you. Notice that there is a system of dynamic lighting. When the projectile moves, there is a light around it, you can see it at the ceil and the floor :
As you can see, there are some pretty pictures which appear when you defeat all the enemies in a room. These pictures have been created by Vincent Stahl :
You may be disappointed by the low framerate of the game. The performance mainly depends on the speed of your microprocessor, the speed of your random access memory, the speed of your graphic bus and the power of your graphics card. For example, I am using a Celeron 700 Mhz microprocessor with 256 MB of RAM at 133 Mhz and a ATI Radeon 9250 Pro. I only have at most 8 frames per second. On a recent computer, you can have about 500 frames per second.
In the past, many people wondered why it is so slow whereas it uses OpenGL. The problem came from the raycasting. In the slow mode (that I removed) of the game used a huge part of software rendering by using a very slow algorithm called raycasting. The bigger your screen was, the slower the game was. The game that inspired TUER uses only software rendering and is between 8 and 16 times slower than mine when you put it into fullscreen mode. My game used OpenGL pipelines after raycasting to increase the speed of the display. As it wasn't enough, I removed completely the slow mode and I don't use raycasting anymore. Look at thee first screen I got when I began modifying the engine :
At the beginning of the modification of the rendering system, the image was vertically inverted, there was an other inversion in the order of color components and I could only see one quarter of the expected image. If you are curious, look at the source code! You can look at an example of model rendered by my viewer which allows me to perform some tests on my methods :
The experimental mode of the game has become very fast as you can see below (tested under Mandriva Linux 2007, 2 GB DDRAM, ATI X1950 Pro 256 MB AGP 8X).
| CRID | Title | Progress | Description |
|---|---|---|---|
| 0001 | Document the source code | 20% |
The source code needs to be documented to improve the readability, the maintenability and the reusability of the whole project.
As some students have already planned to reuse the engine of TUER for some university project, it is becoming more important than
year. Most of the recent classes are documented enough but it is not the case of the oldest classes. The documentation of the code must allow to generate a javadoc. |
| 0002 | Add several monsters | 10% |
Currently, the game contains only one kind of enemy with a very limited set of movements. The aim is to reuse existing models and
to modify them by using the sketches I have done. About twenty enemies have been drawn on the paper. The enemies will mainly use MD3 and OBJ models and maybe models in a specific format optimized for the game. The new artificial intelligence is not ready. |
| 0003 | Convert MD3 files to raw files | 50% |
MD3 files are made for games using technics to compute animations at runtime which is very precise but slow and incompatible with
the approach of the engine. Actually, the engine uses static sets of vertex as much as possible to accelerate the rendering. That's why
these vertices have to be well known before the execution of the game. The solution consists in precomputing a sufficiently large set of candidate animations and to pick one of them at runtime. It is possible by playing each animation with an artificial delta between each frame. All the resulting frames are saved into a file and then, this file can be loaded later to create a static set of vertex per frame. |
| 0004 | Convert OBJ files to raw files | 20% | I can read a OBJ file but I need to adapt it to communicate with the rest of the game. |
| 0005 | Support complex maps | 0% |
Currently, the game is able to use flat maps with orthogonal walls. The size of the map is limited too. The objective is to reuse
MD3 loaders for the maps this time. Some MD3 maps viewer can be found but I didn't find any example of viewer using JOGL, the closest
example uses Java and GL4Java (an old version of JOGL might work with it too). The main work consists in adapting this existing loader to use JOGL 1.1.0 and to bind it with the existing structure of the engine. The hardest task is to couple it with the implementation of the cells-and-portals algorithm. |
| 0006 | Add a progress bar appearing while loading the game | 95% | The progress bar works but it would be fine to allow the users to modify the look and feel more deeply. |
| 0007 | Replace the menus using AWT & SWING by menus using JOGL | 100% | The menu is not finished, some items don't do anything. It would be fine to allow the users to modify the look and feel more deeply. |
| 0008 | Add several reloadable weapons with limited ammunitions | 25% | I plan to add about 110 weapons into the game. The package called "weapon" handles the general behaviour of a weapon and the storage of ammunition. |
| 0009 | Remove the slow mode | 100% | This is done! The game has used less memory since I removed it but some regressions appear in the way of detecting the occupied area and the closest artwork. |
| 0010 | Add a lighting system | 0% | It would be fine to use pixel shading to implement the Phong model allowing per pixel lighting. |
| 0011 | Allow online gaming | 15% | The game is structured to allow to put the model onto a server and the rest onto the clients. They will be able to communicate together by using RMI (faster alternatives will be used if required). The model must keep headless, that's why I removed any reference of AWT and OpenGL in this part of the program. The controllers get the data modification flags from the model, they copy them locally and they refresh the proxy only if it is reaquired before transmitting the data from the model proxy to the view. |
| 0012 | Build a full component-oriented architecture respecting MVC | 65% | Currently, only one package can be considered as a component. The aim is to separate each main aspect of the game (the separation of concerns). Then, it would be easier to correct the code. If a component doesn't work properly, it could be disconnected and replaced by another one. Once the component would be reconnected, the game could go on. |
| 0013 | Add several items and power-ups | 20% | I plan to allow the player to pick up some power-ups to increase his health and its ammunitations as a first step. The medikit is ready. |
| 0014 | Add a time-based animation system | 60% | The current animation system is frame-based. It means that the game goes faster if your computer is able to display it faster. It becomes unplayable on very recent machines and it is not realistic. I plan to select an animation depending on the internal clock and the instant of initialization of the animated object from a static sets of frame. Each model will be composed of several animations, each animations will be composed of several frames and each frame will be a good canditate to form a static set of vertex. |
| 0015 | Improve the accuracy of the collisions by using VCLIP and bounding volumes | 0% | Currently, the collision system is based on very unaccurrate voxels. It is very fast bit it uses a lot of memory. VCLIP allows to handle rigide and deformable objects. I plan to create a multiply layered collision system. The first layer will use a sphere, it will be used to eliminate quickly a lot of candidates in a large room and in outdoor. The second layer will use a box, it will be used to eliminate quickly a lot of candidates in the crowd, in some close fights. The third layer will use directly the structure of the model. It will be used to determine the damages with a good precision. |
| 0016 | Show the impacts on the walls | 95% | The current implementation allows to compute the impacts in the simplified maps where all the walls are orthogonal. I use some polygon offset as some people advised me in order to display the impacts just in front of the walls correctly without any Z-fighting. |
| 0017 | Show the rockets | 95% | The previous collision system has not disappeared and handles the rockets. I have to associate him new entities to display the rockets properly. The best solution would be to remove the previous system and to harmonize the collision system but it requires a lot of time. Currently, the rockets are displayed but are handled not very accurately. |
| 0018 | Show the explosions | 95% | Showing the explosions requires to implement a time-based animation system at first. Then, the main difficulty is to draw the several "embrassed" textures correctly, it might require to disable temporarily the z-buffer. I hesitate in using JOPS. Now, the explosions are displayed but it is not very pretty, it requires to be improved. |
| 0019 | Display a message when the player dies | 99% | A message is displayed above the menu when the player dies. |
| 0020 | Display a bloody screen when the player dies | 90% | I wish to let the blood sink on the screen like in Golden Eye 007. |
| 0021 | Allow to configure the sensitivity | 0% | Sometimes, the mouse pointer is hardware accelerated too and the mouse seems to be too much sensitive. I plan to add a slider to configure the sensitivity in the options of the game. |
| 0022 | Display some figures at the end of the party | 0% | It consists in saving some data about the shoot count, the number of enemies killed and the damages to compute the precision at the end of the party. |
| 0023 | Load and save a party | 0% | I plan to use the default XML encoder of Java to save some settings of the player and some data about the current party taking place in one of the levels. To load the game, I plan to use the default XML decoder. |
| 0024 | Use the cells-and-portals algorithm to subdivide the levels | 90% | The scene graph is almost completely working, the cells are fine. The software view frustum culling doesn't work. I handle the case of multiple connected graphs in a single network set. |
| 0025 | Add a system to compute the geographical modifications | 0% | I plan to take advantage of the use of the cells-and-portals algorithm by dynamizing the levels, allowing the walls to be completely broken. |
| 0026 | Add an anti-gimbal lock system | 1% | Gimbal lock appears when combining 3 rotations by using eulerian transforms. I suggest to use both non eulerian transforms (this has been proposed by Mr Pascal Mignot, teacher at the university of Reims, France) and quaternions to combine efficiently and accurately the rotations. |
| 0027 | Use some occluders in the open spaces | 0% | The cells-and-portals algorithm is not efficient when coming into large open spaces, in outdoor. Using large objects as occluders (antiportals) will allow to suppress some hidden parts of objects to reduce the amount of textures displayed. |
| 0028 | Add some "drivable" machines | 0% | The bounding volume will need to be modified when the player drives a machine. It also requires to modify the view, to draw the cockpit and to respect the property of the machine, the way of moving. |
| 0029 | Allow the vertical look | 0% | It requires to modify the way of treating the mouse events and the parameters of gluLookAt. It requires to improve the way of computing the collisions because they won't happen into a planar surface contrary to what was done until now. |
| 0030 | Implement a spatial sound system | 0% | JOGG and JORBIS are too much limited to implement a spatial sound system. The objective is to modulate the volume of the sound depending on the distance of the noise. In a second step, the physical property of the materials will help to compute how the sound will propagate. |
| 0031 | Allow the monsters to use some weapons and to drop them when they die | 0% | It would be fine to allow the enemies to drop their weapons when they die and when they cannot hold them anymore. |
| 0032 | Add a system to localise the damages | 0% | This requires to use some picking or a raytracing algorithm to determine which part of the body has been touched by a projectile. |
| 0033 | Add a logger to write all traces in a log file to debug | 0% |
It would be better to log all the traces and debugging messages and to put it into a file that would be easier to reach than the
current default traces of Java Web Start. I plan to create a directory containing one file per execution of the game. The naming convention is this further: tuer_log_yyyy_mm_dd_hh_mm_ss.xml. This file will contain also some information about the configuration of the client to help to analyse it to find the source of the bugs faster. |
| 0034 | Display the corpses | 0% | It is not realistic to make the corpses disappear immediately. I would like to let them on the floor to allow the players to shoot them again!! Lol. |
| 0035 | Display the broken objects | 0% | It is not realistic to make the whole objects disappear immediately after they have been broken. I would be better to display some pieces of them spread on the area. |
| 0036 | Add some ant scripts to build the project | 99% | The makefile doesn't work anymore since I began using enums. ANT works fine. I added a lot of targets to allow the programmers to test the game easily. Nevertheless, I have recently noticed that some students didn't succeed in compiling the project in spite of my effort to help them. |
| 0037 | Port the game on the platform called "Android" | 0% | It seems to be complicated as I'm not sure that Android is fully compatible with JOGL-ES. I know it works fine with OpenGL-ES. I have currently not enough time to do it. TUER is not mature enough to be ported even though it uses a little amount of memory. |
| 0038 | Add some XML configuration files to allow the users to modify the game easily | 5% | Many paths should be written into some separated XML files and then loaded at runtime to allow the programmers to add their own elements easily into the game. |
| 0039 | Move the weapon currently used by the player while he's moving | 0% | It consists in implementing a sinusoidal move of the weapon depending on the speed and the acceleration of the player. |
| 0040 | Display the credits in the menu | 100% | The "about" menu item is working fine now even under Windows. It no more uses Swing. |
| 0041 | Replace all flat objects by 3D objects | 25% | I use hardcoded coordinates to generate the data that are loaded and copied into the static sets of data but I will try to convert all these models into OBJ models. |
| 0042 | Show the map at the bottom of the screen | 0% | It is very simple, it only requires to grab the interesting pixels in the map that matches with the current position of the player and to display it in a friendly way. |
| 0043 | Add a small map editor | 0% | The map editor will allow to create some simple maps by defining a set of objects, walls, ceils, floors that may be used further. Then, the editor will associate a colored key (a RGB code). The user will put his objects where he wants by drag-and-dropping them into the map. The data will concern several kind of interaction and will be merged into one. The editor will have to check some constraints. The user won't be authorized to remove an object from the transferable objects if it is already used in the map. The editor will have to assign an unique colored key to each object and to maintain all of them unique. The loadable objects will use the specific format of the application with a supplementary XML file indicating the behaviour of the objects with the editor (the associated icons, the category of object, an indicator about the max count of it in a single map, the associated actions...). |
| 0044 | Add a multilanguage support | 0% | Currently, all the messages displayed inside the game are in English. The aim of this request is to allow the user to choose its favorite language in order to display the message by using it but only for the regular messages, not for the stack trace and debugging data. The implementation will rely on the class called "MessageProvider", respecting the design pattern singleton. The default language will be English. An enumeration will list the available languages and an other enumeration will list the templates of message. This class will contain a 2D array with all the messages of the game. It will be filled by reading a XML file by using SAX. |