Tuesday, July 5th, 2005

• Major changes made over the past few months. Source and media will be posted soon.
  • Replay mode added. The current system creates very large (gigabyte sized) files if the replay is run at 60 fps for all players and objects. So as a compromise, only the puck is recorded at 60 fps while players are recorded at 4 fps (though this is configurable.) The only problem is that this would cause inconsistency between the pucks position and the players position when ever the puck is aquired/released by a player (during passing and shooting.) Therefore, whenever a player aquires the puck, that player is promoted to being recorded at 60 fps, and demoted to 4 fps when they release the puck. This causes a noticeable glitch (though only really noticeable when the replay is run at 30% speed or lower.)
    
    I do have a system of dramatically reducing the replay's file size, thus allowing for everything to be recorded at 60 fps. This invloves recording the players model frame number only, instead of their skeletal articulation, however this would prevent skeletons from being articulated arbitrarily since no frame number would exist for the unique articulation. However, if there is a gaurentee that rewinding is not possible, then the compressed recording system can be used. And in fact, the network system will use this compressed recording to send position updates to clients (since you cannot rewind the server.)
    
    
  • Basic puck physics finished. The puck can collide with the boards, net and any part of the players (including the shaft and blade of their sticks.)
    
    
  • ODE included in the game content but is not used yet. It will later allow the puck (and other objects) to tumble and roll when colliding.
    
    
  • In-game play editor.
    
    
  • Network engine finished with one slight problem. The network engine was originally designed to be transparent to the game. That is, the game system does not know that it is connected over a network and simply thinks the network is a lagged joystick. So each client runs its own simulation (which is exactly like every other client), only passing user input over the network (to the server) to maintain synchronization. However, I realized that floating point numbers are not portable to different CPU's. This would result in every client running a corrupted simulation (relative to the server's simulation.) Therefore I will use a position-update system instead of having all clients run a simulation. The downside is that clients can not accuratley predict what will happen when lagged. The upside is that clients no longer have to process physics or AI since they only need to worry about position updates from the server. The other downside is that now I have to make the game use position-updates (not recode the network engine since it still works fine as is), so this means that you cannot play a networked game yet.
    
    
  • Joystick support added.
    
    
  • Basic GUI system finished, but I still have to draw a lot of GUI components.
    
    
  • Refactored the game engine a bit, so it is slightly faster and the code cleaner.
    
    
  • Three hockey leagues added (International, *HL, RHL)
  
  

Sunday, February 27th, 2005

• Unfortunately, the game is still not playable (and it is far beyond "next week"). However, some important updates were made.
  • Basic sound engine added thus allowing sound effects. On my version of KDE the sound effects are lagged and I still haven't found a reason for this. Testing the game on another machine with Gnome resulted in no delay. Though I did get one run of the game to have no sound lag (on KDE), but I don't know what caused it to work. I am not sure if KDE is the problem, but from what little information I was able to gather, it seems like KDE might have something to do with it.
    
    For testing purposes, I used sound effects from Mike John's Hockey Simulator. Download the media (graphics/sound) zip file for his game if you wanted to here those sounds (though they were only tests and sounds are not generated by any players yet).
    
    
  • File engine added. Now there is no need to extract media (graphics, sounds, etc.) before playing the game. The game will load files from the media archive files as needed. However, some media (such as sounds) cannot be directly loaded into the game for use. Instead, these files are extracted and copied to a temporary directory (which is set to "/tmp" by default) and are used by the game. When the game terminates normally it deletes all of its temporary files.
    
    
  • User control has been added. The game is not playable, but you can still control three of the home team players. Details about controls are in the file "rph_stuff/rph/controls.batch". When trying to select the player nearest the puck, you will have to wait until the referee gets ready at the faceoff dot. This is because the user control selects only from "iced" players, and coaches don't ice any players until the referee sends the faceoff signal. (In this context, "ice" means players scheduled to be on the ice, not players who are on the ice at the moment)
    
    Currently, all you can do is select players, skate around (very poorly) and do a simple wrist shot (there is no aiming other then shooting the puck in the direction you are pressing at the time). There is a lot of animation adjustments and control decisions to be done before it will be comfortable to control a player.
    
    If you have idea's on how a player should be controlled, then send me an email.
    
    
  • Added a goalie (with half a head) and no animations (not much time for modeling).
    
    
  • Simple collisions between objects has been implemented. However, only player-player collisions are enabled. So you can't bump into the puck, goalie, referee or the net.
    
    
  • Basic AI framework is finished. High level AI (which will actually run the game) has been delayed for a moment. This is because I have decided to create a simple tool that allows users to create play stratagies in a Graphic User Interface (GUI) rather then C code. These play stratagies will be used for everything from faceoffs to defensive and scoring plays.
    
    
  • Network "support" is present however there is no "engine" to manage it. Games will not communicate with each other (directly) but it is possible to control the game remotely. The network engine may be completed in parallel with the play-developing tool since remotely coaching teams is a core feature of the game.
    
    
  • Improved models for the game have been developed, thanks to Michael "miga" Gangolf .
    
    However these models are not available in this update yet so as to allow me some time to further detach the game from 3DRomED. This will allow great modelers like Miga to by pass 3DRomED and add content directly to the game.
    
    ".3dr" files provide 3D model data, animation, collision detection and texture mapping. All of which must be duplicated inother file formats (or a combination) before 3DRomED can be completely bypassed.
    
    

  Monday, February 7th, 2005
  

  • Basic AI almost complete, simple playable version should be ready by next week.
    

  Monday, January 24th, 2005
  

  • The final non-playable update is now posted (you should be able to at least play a period in a future update).
    
    
  • You can't do much more in this version then you could in the previous, however the framework for the AI and game play is now set. Also a referee was added. The referee is the main entity that will get the game going. Also in this version is the improved player rendering system (which still has bugs). In fact, the vast majority of time was wasted tracking bugs in the renderer. For this reason, rph now supports being built and linked statically for debugging, since I couldn't get this to work with the shared objects. However using shared objects is still possible (though static building is default now).
    
    
  • This version also doesn't include the gimp (.xcf) files used to create the bitmaps, since they just take up space for now.
    
    
  • Rendering of the glass is disabled by default since the rendering system for that feature needs to be fixed. However you can enable it in the configuration file "practice.cfg". Right now it just drops the frame rate slightly and doesn't look that good.
    
    
  • 3DRomED now has the ability to export OBJ files, though it has problems with some models. Also I still haven't added the ability to allow 3DRomED to load model textures from different directories.

  Sunday, January 16th, 2005
  

  • Optimized the renderer for the players. They will now be rendered with glDrawRangeElements instead of glDrawArrays. However, there are very minor texture glitches due to the fact that vertices now can only be mapped to one set of normal and texture coordinates (this is a problem that will be easily fixed.) Also, it seems as though this is as fast as the renderer is going to get without using Level of Detail (LOD) management (which will be done as a final step), and I was having problems getting glLockArraysExt and such to compile, so I will deal with those later.
    
    
  • Created a low poly shadow model and implemented simple stencil shadows. This will most likely be the last graphical enhancement for now, as I will focus soley on AI and game play.
    
    
  • I have noticed that the timing system for the game is not working consistently. The graphical frame rate will start out very high, then drop by about 75%, then climb up to 90% of the previous maximum. This cycle is repeated for the duration of game.

  Saturday, January 15th, 2005
  

  See change log for details.
  
  3DRomED wasn't included this update but will be in the next one. Among other bugs, 3DRomED has problems find textures for models, so a method of selecting a base directory will be added.
  
  In this update you can't do much more then make one player walk around, and move him from north to south. Also, the physics system needs to be updated because you can still make the player go through the boards.
  
  Also, you will notice a slight pause when the game loads up and is compiling alpha faces for the arena. The game is generating a bsp tree for displaying the glass and this takes a while. The bsp code also is not working correctly, and will be fixed in a future update. However at the moment, it only affects transparent/translucent polygons so it is not a big problem.

  Monday, January 10th, 2005
  

  Basic generic game engine up and running. The game is still not playable as the physics system is not complete and there is currently no AI (the core feature of the hockey game).
  
  At the moment the source is being cleaned up (a bit) and finalizations on the physics engine design are being made. With 3DRomED finally debugged to a useable state, the physics engine is the main road-block that is stalling the progress of the game. This is because systems like the AI are dependent on a fast and reliable phyiscs engine.
  
  To date, 80 to 90 percent of the work was spent on 3DRomED and its supporting drivers (and it still has issues). However, with it pretty much out of the way, it shouldn't be long before the game is playable.
  
  Poor quality textures currently make the game look much worse than it should. Hopefully that can be remedied.
  
  Downloads and screenshots are now available.
  
  

  Wednesday, December 1st, 2004
  

  3DRomED completed to a useable level (apperantly it wasn't as useable as I previously thought). Work on the actual hockey game will now begin.

  Saturday, September 18th, 2004:
  

  3DRomED (3D model editor) is still buggy and missing features, however it is ready for use. Basic 3D models such as the hockey nets and the player are currently under construction.

  Wednesday, September 8th, 2004:
  

  Pro Hockey website is up and running and some of the graphic editing tools are almost complete. Specifically, the 3D model editors are almost finished and production of the player models will begin soon.