Other things striked back as well, but Jeff told me to make this the title.
This week we spent a lot of effort integrating networking into the game engine. We now have TCP-based networking integrated, as well as a general purpose message sending and framing system that’s easily extensible for when we need to send custom messages in the future (right now we’re only sending input events and transform data). There are some issues, but that’s what the next six weeks of debugging are for!
We’ve also added some cool graphical features, made more strides in terms of art assets, and gotten further along in our physics/collision detection system (although we’ve hit some roadblocks in the latter).
Morale is good again. Everyone seems to have stuff do, and even though we’ve already had a couple of occasions where team members had to duck out, everyone was always notified ahead of time.
Here are some more screenshots of graphical stuff (the second and fifth are in engine, others are Blender), as well as a video of networking in action.
OK, W3 Progress Update:
My concrete goals for the week was to work on animating models, and to skin the player model.
I accomplished both of those, though the animations do seem a bit unusual. Basically, I determined that the file exporter from Blender doesn’t… well… work. But the good news is that we won’t be exporting files in that way so we shouldn’t have to worry about that. Still, there may yet be some issues with animated models being rotated for no clear reason. If that happens though, it should be easy to correct for. Just keep an eye out if animated models aren’t visible as they may have rotated under the ground. Importing the objects separately from the scene should fix that though.
Next week I will help Dexter with the collisions, and do whatever else needs doing.
I’m doing quite well, I think I did a lot more useful work this past week.
Last week’s goal was to implement the entire collision detection system for the game. This included implementing axis-aligned bounding boxes, spheres, raycasting, capsules, and an octree. I pretty much only finished the octree, and I’d say as of now most of the system is untested. Raycasting should be fully functional, at least for boxes and spheres contained in the octree. There are still lots of holes to plug throughout the system, and since I was traveling for the weekend, I wasn’t able to get as much done as I would’ve otherwise.
That being said, a lot of time went into designing and thoughtfully crafting the collision system. I’m very confident that the work I’ve begun can effectively be split up into smaller pieces and spread out to others on the team. What began as a monolithic task is now a short list of unimplemented methods in appropriately named classes.
Getting collision detection working this week is imperative. I may not need to cover all the possible cases (I doubt we will need capsule-capsule collisions immediately) in order to provide a usable API for the gameplay programming team, but the sooner this code works, the sooner we can start building the actual game.
After I finish making the collision detection system usable, I’ll transition to gameplay programming. By that time, we will have enough puzzles designed to get started on building them in-game.
I’m feeling very good about where the collision code is, and about how well our group is progressing with respect to the networking integration. I’m reserved, but optimistic. My airplane has plenty of fuel, and nothing appears to be on fire. Yet.
Last week, we tried to get the Server to able handle multiple clients as we had previously achieved basic single client functionality.
We were able to have multiple clients running using a select like functionality!
We were not able to integrate it to the rest of the engine because we are still making our messaging system more robust, since we have to handle multiple components of the engine. E.g. Inputs and Objects. However, since the basic networking is finished, it won’t be particularly difficult. Also, right now each client does not have complete autonomy over its inputs, because the server broadcasts all messages and the client does not yet know how to process its specific messages.
Next week we will increase the robustness of the engine, so that each specific client will be able to have its own autonomy. But the main goal of the week will be the actual game design: what are the puzzles and how will they be integrated into the overall game?
Right now I am still feeling pretty confident about the network side of things as my partners for networking, Pavan and Jason, and I have finished most of the functionality. However, since we are thinking about the game this week, we will have to think about the gameplay design. And that means a lot of decisions.
Networking! From low level socket interactions to high level messaging, I worked primarily with the networking team this week. I specifically worked on having the server and client process as many messages as possible per tick (rather than leaving extra messages in the TCP buffer), handling receiving messages from multiple clients simultaneously, as well as how to properly delegate messages.
The engine we’re using (Jeff’s) has the general idea of a “component”, essentially a script that’s attached to every game object. There are built-in components for things like Transforms and Materials, but you write your own components to implement game logic (all components have callbacks for things like frame updates or collisions).
What I worked on is giving every component the ability to register an ID as well as serialize and deserialize itself. The hopes are that the server and clients will synchronize component IDs at the start of the game, and from then on it’ll be as easy as cycling through every registered component and sending/receiving their serialized forms across the network. We have this working with Input and Transforms at the moment, but it needs a bit more work to be fully general purpose.
Along with that, I also want to work on solidifying the puzzles and floorplan of our game this week (in fact this’ll be my main priority). Once Dexter finishes collision detection and the basic physics system, we’ll be immediately jumping into actual game implementation. Jeff also needs to know the “final” layout of things in order to properly model the rooms and props of the game.
I’m doing fine morale-wise. I kind of wish we were further ahead in some regards, but given how ahead we are on the core engine as well as graphics support, I think that overall we’re making great time. Hopefully we’ll be able to present a puzzle next week!
This week I did more art and graphical effects for the rendering engine. As far as art, I finished up a model for the starting prison room, and created the basic layouts for the security room, control room, and escape pods. I planned to do more rooms, but as we haven’t finalized the room layout or puzzles yet, I don’t know what we need yet. Instead, I did more programming work and implemented Screen Space Ambient Occlusion, and Parallax Occlusion Mapping. Next week I intend to do more room art and possibly implement point light shadows. My morale is improving as Jason only bugged me about it once this week.
My goals for the week were to help get the networking aspect of the game working with multiple clients. This included being able to tell which messages were for which client, as well as making sure that all of the clients were communicating their actions with the server.
We were actually able to accomplish all of these goals and now have a game that is working with a server and multiple clients in which each client is able to move around independently and see other players move around as well. The clients were sometimes a little laggy, so we were planning on fixing this next, and then moving on to communicate other messages between the client and server.
I think the reason we were able to meet these goals was just by putting in a lot of work during the week and weekends, and we are probably going to have to continue doing so to continue our pace going forward.
My goals for next week are to work on a component registration system that allows the server to assign unique ID’s to each component that is in the game. In the game initialization, the server will send a table of each component and its corresponding IDs to the clients, and these IDs will be updated while the game is running.
I feel good about the work we did this week and I feel like our team is moving forwards on schedule if not a little faster than I had anticipated. I think that if we continue this pace, we will be in great shape for the rest of the quarter.