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
- 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.
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
- 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
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
- 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"
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
".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
- 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
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.
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
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.