While working on cleaning up the avatar movement messages, I decided to move the rendering and scene updates to their own threads. This certainly smooths things out quite a lot! For one thing, input device updates don’t get starved whenever the rendering slows down. There are a few concurrency issues that I still need to work work out, however.
I’m keeping the game offline until I finally reconstruct everything that I have deconstructed!
I’ve been re-writing the game’s avatar movement code in the client and the server. I want to smooth things out once and for all! It’s finally time to retire the test code that has currently been in place for years. I’ve also been researching a bug that can cause horrible render lag while running in full screen. I hope to resume testing again soon!
Finally! Everything is coming together in the game to the point where I can finally work on the combat system. Now that the code for the friendly NPCs is progressing well, I’m starting to work out all of the details for the enemy NPC. It moves through the pipeline a little differently than the other avatars. I’ve been very pleased this week with my progress, because most of the required code is in place now! Although incomplete, I’m leaving in the proper hooks, so that I can also later add “player killer” features (i.e. un-friendly players).
Another new addition to Been There is the skill system. Experience points (XP) can now be applied towards the player’s available attributes. Skills can also be opened up (at a cost, of course) for further training.
The Orion Engine continues to live, and it sure is rocking and rolling!
Finally got around to adding some NPCs into the game. Currently you can chat with them. Soon, they will be used to start quests, and to provide rewards, etc. It’s very cool that I have this working, since enemies will derive from this code. So, this means I’m one step closer to getting the combat system up and running!
I decided to re-write the mesh load and save routines used by the engine. They were previously using a recursive algorithm, which quickly caused the stack to fill up on larger models with deep hierarchies. Running into a stack overflow situation is simply not acceptable.
I needed to write the objects to the mesh file in depth-first order, similar to the original recursive implementation. Now I see why people like recursive functions, it was very difficult to refactor this into an iterative while loop! I basically had to implement my own stack, that allocates from the heap instead of the limited call stack. Also, keeping track of the nodes that have been visited while unwinding the stack is key.
I’ve been hard at work implementing new intersection tests, and dealing with collision and response algorithms. Pretty tough stuff to make work correctly and smoothly under all circumstances!
I’m basically breaking up an area into distinct height levels, then doing 2D intersection tests between a circle (the player) and a line segment (i.e. a wall) based on your current level. In 3D this is equivalent to an intersection test between a cylinder and a plane. 2D just saves us a few CPU clock cycles, which are always very valuable!
Turns out I wasn’t extracting scaling properly in my 3ds Max exporter plug-in. For one thing, if the local transformation included any scaling, it could cause NAN problems to arise while converting the matrix rotations into quaternions for the keyframed animation system. So, I added new methods to the 3×3 and 4×4 homogeneous matrix template classes in the engine to properly decompose a matrix (without shearing) into individual translation, rotation and scaling values. This allowed me to properly export all of the animation data now.
I finally feel the game’s network code is very stable. I found a pretty major bug on Christmas day that would cause file downloads to randomly stall. It had been nagging me for a while. Of course, this severely hurt my update system. Fixing it made me very excited! Then today, I found the remaining bug! All I can say is… sweet! Wireshark sure is a great tool, lol.
I updated my test client, and test server applications to really put the code library through the loops. I can send HUGE files back and forth, create an exponential feedback loop of data, send malformed packets, small packets, big packets, too many packets, too few packets, etc. It helped me uncover a few issues, including a fairly nasty concurrency issue that would cause the server to puke and write it’s minidump.
The game client now queues up all avatar update notifications. For example, if you walk into an area with a LOT of avatars, they are slowly and gracefully “spilled” into the current scene. Instead of trying to load all of the avatar objects at once, abruptly holding up rendering. This would be bad!
There are a lot of fine details in this implementation that must be paid close attention to. For example, network messages must be queued up while an avatar is being loaded on its own separate thread, for further processing later. Also, what if an avatar leaves the area, and you haven’t even finished loading it yet! Superb object synchronization is a must. Nobody wants things to get out of whack!
The game server finally properly handles avatar update messages. Basically, all avatars are grouped into small areas. These areas align with the land block grid system used by the terrain renderer. As a player moves in and out of a particular land block (or entire land area), neighboring players are notified of this change. Avatars are thus dynamically loaded and unloaded on demand, based on where you currently are. Of course, to further optimize avatar rendering, distance and visibility tests are also incorporated by the client.