Last night, I dreamt of boxes and spheres,
Breakpoints alone could not sway my tears.
Colliders rebelled and deafened my cries,
My debugger cackled: its numbers were lies.

How foolish was I—to think that alone,
I could code for them all—even a cone!
No, the price of hubris was far too great,
For collision detection, I surely now hate.

Those of you who seem to relate,
Harken my words: before it's too late!
The networking stack has now coalesced,
The boxes are working (but my spheres aren't the best)

More time will be needed, to wrangle these,
As errors linger like an infectious disease.

—Dexter Friedman, Nodes from an Octree

Author’s Note: The poet would like to inform readers that after a temporary loss of his sanity, he has made a full recovery. Collision detection is working well enough to start programming game logic, and it is fully integrated in the core engine. Tune in next week, for another epic tale filled with adventure, intrigue, and romance!?

Besides all of that, we also worked on furthering the network integration within the engine. Now objects magically sync their own data across the network (including not just movement, but their creation and their visual representations). We also prettified the graphics even more (of course), and made input more modular (we really want that controller support).

Stepping out of pure engine additions, we all spent most of Tuesday on game design, essentially white-boarding out the entirety of our game’s floorplan, including creating fun puzzles for the most of the map. We’re essentially 90% on the design intricacies of the game we’re making, so now that collision detection is done in some regard, we’re happy to sit down and actually implement some gameplay.

It’s kind of funny—we all feel like we’re falling behind, but if you check out our project schedule, we’re actually almost 100% on track (even down to silly things like point light shadows in week 4, wow). We spent a lot of time solidifying the underlying infrastructure, and even though there was a steep cost, we feel that this effort will result in less regressions in the future.

Hey, here’s a cool in-engine picture. Look at how pretty it is!

Those shadows!! Look at them!!!

Team Reports


This week I was planning to help Dexter with collisions, but that didn’t end up happening. Instead, I worked a lot on design, finalizing the floor plans for the spaceship and introducing a new puzzle that we’re prototyping. I also implemented jumping in-game, which included sending the “fire” data to the server. My current implementation is a bit hack-y in that it lacks collision so it assumes that the “floor” is at y position 0, but that can easily be fixed.

My not helping Dexter was because Jeff did that instead while I did design and jumping.

Next week my goals will depend on whatever the team needs me to do. There isn’t an obvious “next thing”, so I’ll probably just fine whoever needs help and help them.

My individual moral is quite good.


(re-read the intro of this blog post)


One of our concrete goals was to finish the network code and the overall robustness of it.

I completed a separate goal of making button maps load from a config file, so that I can increase the modularity instead of having it hardcoded.

Originally we thought making the network code more robust would be quite trivial, but because of the complexity of the engine there were a lot of things that the network code has to account for. For example, mapping the network code to the engine components, and the creation and destruction of objects, which would be more involved than simple transforming of objects. And since we became a group of three in the network side, only Jason and Pavan have been really working on the network code. And since the code is built on top of itself and it would be unfeasible and inefficient to sit three to a computer, I have not been able to be a part of the network coding.

If the network code and the collisions come together completely, I plan on working on gameplay as soon as possible. I have a couple of puzzles in my mind that I would like to create.

It’s already week five and I’m beginning to feel behind. And since I can’t be as useful as I would like on the networking side, I’m beginning to feel a little bit low in morale. However, I remain hopeful and I am excited to be able to begin on gameplay soon.


At the beginning of this week everybody worked together on floorplan design and puzzle design. I submitted some ideas I had, as well as worked on furthering other peoples’ ideas. I really like the puzzles and environment design we have in mind, and am excited in progressing in that regard.

My major goal this week was to further the component registration system–essentially getting all of the parts of the game to talk to each other across the network automatically without us having to scatter sendAcrossNetwork() and such throughout our game code.

It took a while to get working, but I’m quite proud of how it’s coming along. We can now start from a completely blank, logic-less scene on the client-side and have the server do all of the heavy lifting when it comes to creating objects, assigning models, and positioning things in 3D space. The ideal is that the code one writes for a multiplayer game will be almost exactly the same as the code one writes for a single player game. If done well, this should help immensely later on–we won’t have to worry if we ever forgot to send network data for an event, because the engine will do that automatically. Real cool stuff.

This week, Pavan and I need to extend it to send lights and cameras over the network as well (right now it just sends concrete objects). As we finally have collision detection working, we can finally work on gameplay as well! I’m going to continue something I started working on a while ago before I joined the networking team—a system that registers all pressure plates, levers, buttons, doors, gates, etc. through the names we give them in Blender, and then hooks them up so we can start getting some puzzles going!

I’m kind of burnt out at the moment; networking code really isn’t my favorite, but as the person with the most engine experience who isn’t tied up (i.e. Jeff and Dexter on Physics) it was necessary for me to join the networking team to fully design integration. Because of that I’m really happy that we now have prototyped physics so I can do what I signed up for, gameplay programming.

Besides that I’m decent morale-wise. I think our team needs to do some reworking with both priorities as well as doling out tasks–we’re running into issues where some people are stuck with a lot of stuff to do, and others aren’t really given anything, which doesn’t help anybody.


This week I worked on creating the art for the first puzzle, improving the lighting system, and helping Dexter with the collision. For the art, I created the main models and textures for the first puzzle that we were trying to finish this week. I then improved the system for point lights, the most notable improvement was adding shadows (directional lights already had shadows). With the collision, I created a way to edit and load colliders from Blender into the engine. Later in the week I also helped Dexter to debug his collision code and had a small part in finally getting it working.

For next week, I am going to mostly step away from art and graphics, as other areas are falling a little behind, while art and graphics are slightly ahead of schedule. I aim to have the first to puzzles mostly working by the end of next week. This will mostly entail helping to tie together different areas, as well as gameplay programming. As for my morale, I am slightly disappointed to have to stop doing visuals, but am happy in what I have been able to do.


My goals for this week were to be able to create and destroy objects across the network. I was able to write an initial basic implementation of this, and helped Jason to further extend it. We were eventually able to do the initial setup of our basic world with all of the objects being created on the server, which would then tell the clients what it was creating, what meshes/transforms it was applying to those objects, and it was able to keep these consistent across all clients using unique IDs.

We were unable to finish the destructions of objects in this way, but knowing what we know now, I think it will be much easier. We ended up spending a lot of time on one bug in particular that had to do with the way that meshes were being applied to certain objects, but we were able to fix it. This prevented us from moving forward with the delete functionality, but we may postpone that further until we actually do need to be able to delete objects from our game. I was also gone this weekend, so I was unable to help as much as I normally could have. In addition to the create/destroy side of things, I was also able to ensure that the clients were only sending messages when they received input (instead of all the time which is what it used to do).

My goals for next week are to continue working on the message passing between client and server to get a fully consistent world, and then hopefully begin integration with the collision detection branch that Dexter has been working on.

I am still feeling confident that we are moving at a good pace. Collision detection is taking a little longer than I thought it would, but I think we have a good grasp of what exactly our game looks like and what puzzles/traps it has so that we will be able to hit the ground running once we integrate the collision detection branch.