/* Excessive Furniture */

CSE 125: A Postmortem

Author’s note: whenever you see I, it is referring to Jason Lo, the main author of this post. The post is however written to reflect the views of all team members.

We did it!

It’s been an extremely long ten weeks. We all spent most of our time on this project (to the point where I personally didn’t go to any of my other classes’ lectures!), and even though we didn’t end up having to pull any all-nighters (save for Dexter, but those were totally of his own free will) we obviously put a lot of effort into things. ¹

Now that everything has been finalized, let’s talk about the ten weeks in detail.

Overall Impressions

Q: What game did you seek out to make? What did you end up with?

At its core, we wanted to make a cooperative puzzle game. We’re all big puzzle game fans, and furthermore we’re all big game design nerds. A lot of the games that come out of CSE125 are competitive, usually in the arena shooter/brawler vein. While competitive shooters certainly do require game design (I’m not about to tell you that Quake isn’t a brilliantly designed game) there are a lot of givens and defaults just because of the genre.

A puzzle game however has almost no prior assumptions in terms of mechanics. Furthermore, a puzzle game is all about the puzzles, which require careful design even outside of the mechanics of the game. We knew a game like this would be difficult to make in the given timeframe, and that we’d probably end up spending a much greater portion of our time on design vs. implementation compared to the other groups. I definitely don’t regret that decision.

Unfortunately, time does catch up. A big part of our game (it’s about robots escaping from prison by the way) was supposed to be the competitive aspect. Not all of the robots were going to escape the prison ship, and we wanted puzzles that while forcing the players to cooperate would keep them on their toes, knowing that at any time any other player can just “accidentally” push the wrong button and open the trap door rather than the real one. Due to the time restraints of the class, we weren’t able to explore this idea, at least not the point that we would be satisfied by. We ended up dropping the entire competitive aspect around Week 8 and focused on making it a strictly-cooperative puzzle game.

The design goals we had during the competitive-phase of our game production kept on through the entire project though. Each puzzle was designed and sequenced in a specific way to force certain player interactions: the prison puzzle cannot be solved if any player doesn’t cooperate. The corridor puzzle teaches players that even if they can split up, they shouldn’t necessarily. The keycards teach the players that the puzzles are connected, even if the individual rooms are separate. When you have four players, you have four actors that you have to control simultaneously, and I feel we did a good job of it.

Q: What changed when it came to implementation expectations?

We actually implemented a lot of the crazy technical aspects we strove for. From SSAO in week three to octree-based collisions (we had ramps! Ask anyone who’s ever written a game, and they will tell you ramps are impossible), tech wasn’t often a problem for us. We even explored audio much more than I had ever expected. We did however struggle more with particle effects and animations than we expected, and ended up having to drop both.

Q: Did things go to schedule?

We’ve joked a lot in the prior blog posts about how even though we kept feeling that we were falling behind, we would just check out schedule and find out that we were on track! We definitely underestimated ourselves in many regards when making the schedule.

The big block, one that you’d see coming if you read any of the prior posts, was collision detection. We strove from the beginning to do collision the “right” way, and that cost us dearly. Not only did implementing the octree system take much longer than we expected (we didn’t “stop” working on collision until week 8!!) but it cost us in other regards. Implementing and testing puzzles is surprisingly difficult when you can’t walk into things!

We might have underestimated ourselves, but we surely overestimated Blender. Blender is not a level editor, and even with our ActivatorRegistrator ² system, we ended up fighting Blender much more than we should have. There really wasn’t an alternative though—a puzzle game requires some sort of level editor, and making a level editor is essentially making a game in itself.

Implementation

Q: What methodologies did you use? Which ones worked well?

We didn’t use any particular development methodologies when making the game, no Kanban boards or user experiences or anything like that.

When it came to development, we did stick to a Git Flow-esque ³ workflow where we had master and develop branches that housed most of the code, and had independent feature branches that would split off and merge back into develop as required. We rarely ran into merge errors, due to use preferring a rebase-based workflow, causing us to deal with merge conflicts up front rather than pushing them nervously to the future.

We used Dropbox for asset management, which actually turned out to be much more of a hassle than we expected?? We routinely ran into syncing issues, and at some points Dropbox would serve certain team members us older versions of files that we had uploaded, while giving newer versions to others. Very strange stuff.

Q: What difficulties did you have in implementation? Did anything turn out easier than you expected?

We’ve gone to lengths explaining how difficult collision was for us. We strove to do it the “right” way, with an octree-based system that would separate our space into octants, allowing us to only consider collisions and raycasting in a local space, rather than across all colliders in our world (of which there were quite a few). It turned out absolutely fabulous though (ramps!!wow) so it’s not as if it wasn’t effort well-spent.

Networking also turned out to be quite difficult, even more difficult than we had imagined going in. We decided to roll our own TCP stack rather than using a library, so we had expected difficulties, but we ran into problems much more frightening than the lag and desync we were expecting. We ran into issues with some clients refusing packets after a certain period of time (with no TCP errors thrown), we ran into issues with a single client stuttering and cause all other clients to follow suit, and we even ran into a bug we deem the “Sanic” bug, where randomly on start all of the clients will run at superspeed for 10-15 seconds. That bug we never figured out how to fix…

Sound was our saving grace. We used the popular FMOD library for sound, and it works extremely well ⁴. No qualms, it just worked. One of our team members, as well as one our friends, even went on to implement FMOD-based sound in their 167 projects by our suggestions, and were very happy with the results.

Q: Time to brag: what parts of the implementation were you really proud of?

You don’t have to look at our game for very long to know it looks good. We had resident graphical wiz-kid Jeffrey Johnson on our team, and that decision really paid off. Besides literally doing all of the art, Jeff did most of the graphics programming, giving us real-time point light shadows, screen space ambient occlusion, and even IES-profile simulation for complex-shaped lights. It even runs relatively smoothly ⁵.

We’re also really happy with the network infrastructure (not the TCP code driving it all, mind you). All stateful objects, whether it be transforms, mesh data, or even sounds, in our game essentially send their state on changes across the network with no developer interaction. That means that you can write game code as if you were making a single player game, and you got multiplayer for free! We paid a rather high up-front cost getting that to work (Jeff also had to yell at me quite a bit before I agreed to implement it) but I’m so happy with how it turned out. Writing game code is a breeze when you don’t have to worry about sharing state over the network.

Q: Did you use anything besides the expected C++?

Not really, our game was written with C++ and OpenGL. We did however use GLSL a lot for shaders. The only advice we can offer for that is NVIDIA Nsight is greatly recommend for shader debugging, because you’re going to have a lot of fun debugging shaders without such a tool.

Q: How many lines of code did you write?

According to Cloc ⁶, we had 12376 lines of C++ and 824 lines of GLSL. This includes graphical code from the 167 project our game is based on.

Q: How did you handle media content in your game?

We used Blender exclusively for our 3D modeling of individual scenes as props, as well as UV unwrapping t. Actual materials were created with the awesome Substance Painter software ⁷. Rather that directly attaching materials in Blender, we had a custom configuration-based system that allowed to write material data in .ini files, allowing us to change properties such as textures, tints, brightness, and the like on the fly without having to reopen Blender. To get things into our game, we used ASSIMP for model loading, and SOIL2 ⁸ for material loading.

We also used Blender for stitching together the individual scenes and props, as well as giving them metadata that our ActivatorRegistrator system took advantage above.

For sound, we composed audio with Audacity, and did voice effects with the awesome Melodyne software. We included audio in our game with FMOD.

Q: Even after all of the above, would you have rather started with a game engine?

We briefly discussed this among those of us who have experience with the Unity game engine. We estimated that we could probably remake our game in its current state with Unity in about a week, with the only thing we’d need to learn is networking (I hear though that in recent versions Unity networking works really cleanly). Our game engine doesn’t really do many custom things, and having an existing game engine would give us way more time to spend on game design, something our game sorely depends upon.

Of course, we’d have to do things the Unity Way, and any straying from the Unity Way would cause harm. I could see Unity physics not working extremely well for a platforming game, and Unity also wouldn’t necessarily give us as much freedom in the Graphics department as raw OpenGL would (although we would get a lot more effects for free).

Q: Did you use any major libraries? What are your opinions of them?

We rolled our own graphics, our own physics, and our own networking. I’m perfectly happy with our graphics, and from what I’ve heard, if you’re not doing physics simulation (which we certainly aren’t, realistic physics make a terrible platformer) then using Bullet will be a struggle, even if it gives us collision for free.

Networking on the other hand is something we’d definitely use a library for. At the end of our day, our underlying networking code just works, and not much more than that. Using a networking library that hundreds of people have worked on gives us reliability and performance. Plus, if we were making an actual game, we’d of course use UDP over TCP to avoid the overheads of TCP, and a networking library might abstract away the technical differences of TCP vs UDP.

Q: You’ve talked about group dynamics in a game, what about in game development?

Working in a large group is often a balancing act. If everyone is off in their own worlds, not following anyone, people will get lost and the project will never get done. However, if there is one leader that no one can agree with, then mutiny would happen.

In Elton’s personal experience when working with a 60 person team in CSE 112, they started off with no clear leader or instruction and ended up in the first boat: no real tasks, no clear place to go. But when they turned towards the leaders, nobody really agreed with any of them. Only when a clear leader emerged and everybody’s skills and experience lined up right, did things start rolling.

One thing that we quickly learned is the need to trust the competency of your teammates ⁹. I ended up being the task manager of our group, and therefore had to trust that Bert could indeed get wall-sliding to work, or that Elton could indeed get lights to sync over the network. It’s especially hard to trust people you’ve only met recently, but if you don’t and instead just try to implement everything yourself, you’re just going to run out of time, and drive down morale. Trusting everyone to be competent allows you to most effectively divide up tasks which speeds development up along.

Q: What would have you done differently if you could do CSE125 all-over again?

First, I’d find a better to develop on the lab machines! We spent 15-30 minutes setting up every single time due to the computers being wiped. Elton had the right idea, making an external hard drive his development station.

Development-wise, we’d work a lot harder to get something playable right at the front. It wasn’t until Week 8 that we really got to play around with our ideas and see what was viable, which obviously hurts when it comes to proper game design.

We’d also really try to get hold of an artist. Jeff did a great job, of course, but even Jeff’s skills and time are limited. Having dedicated people would have allowed Jeff to do more programming, as well as getting potentially even cooler art-direction that our feeble programmer-minds could have never thought of.

Q: What UCSD courses do you feel prepared you for CSE125?

CSE167, obviously. It’s the only OpenGL introductory course you’ll find at UCSD, and even if you’re not knee-deep in Uniform Buffer Objects and Fresnel coefficients, you really should know what the Model, View, and Perspective matrices are, as well as how transformations work, the role of the camera, scene-graphs, all kinds of stuff. CSE167 is also one of the few classes to allow freeform final projects, which will really help you when coming up with a CSE125 project.

CSE124 is almost essential if you want to start networking with sound footing. A lot of our initial networking exploration was just repurposing old CSE124 code.

Q: What was the most important thing you learned in the class?

I can’t speak for my group, but the most important thing I learned in this class is that shortcuts hurt. It is way too easy to do things the “easy” way just because it’s the quickest, or not very fun to take seriously. Of course, when you just want to get something on the screen, doing things the easy way is often recommend. But if you only take shortcuts, and you don’t remedy those shortcuts as soon as you can, developing actual structure rather than just hacks upon hacks, your codebase will become very unwieldy very fast.

We put a lot more effort into a proper code than I’ve ever done in any of my prior projects ¹⁰, and even with the outrageously-high upfront costs, I’d do it all again because it made our code so much easier to reason with once we started reaching crunch time and brainpower started dropping. Good code pays for itself.

Media

Here’s some media we’ve collected of the game. Enjoy!

Feedback

Q: What books do you recommend for learning?

Real-Time Rendering by Akenine-Moller, Haines, and Hoffman is a book that Jeff recommends time and time again when it comes to all things graphics (Dexter even found use for it when making his collision code!). Thankfully you guys provide the second edition of the book.

Not a book, but learnopengl.com is an absolutely fantastic resource for anyone getting up to speed with modern OpenGL programming. It teaches everything you need to know (and then some!) while remaining completely approachable.

Q: What tips do you have for future students?

• Start early. No, really. this isn’t CSE131, you can’t do the assignments the day before they’re due.
• Establish some sort of methods of communication right from the beginning. We used Slack.
• Decide on some sort of source control. Make sure everyone is competent with it, and make sure to establish some sort of etiquette on how it should be used.
• Always communicate what you’re doing. The worst feeling is when you’re halfway working on something and then find out your teammate already did it.
• Make sure everyone is doing something at all times. Even if it’s just looking through code to make sure they understand how it works, people should always be busy. If someone’s not busy, then
  • Someone else is too busy and tasks need to be split up
  • You forgot something and are therefore not planning well
  • Someone is blocking the project and that needs to be resolved ASAP (maybe you can help!!)

Q: Any final feedback?

For me (and the others I’m sure), CSE 125 is a course that I’ve been waiting to take since my freshman year at UCSD, and I’m so happy that I’ve been able to be a part of it with my group members. So definitely don’t stop doing it! I want to come by next year and watch next year’s presentation!

One of the biggest blocks for us was the work environment. From the computers being reset on log-off (we’ve lost work a couple of times due to that), to non-CSE 125 students taking space in the lab even though it’s reserved, to the darn department destroying the hallway and making all foot traffic go through us, B220 had to have been my least favorite part of CSE 125. Obviously the latter problem was a situation specific to us, but the rest were actively bothersome. The problem though is I can’t really see how this would be resolved—it honestly seems like things were handled the best that they could.

Obviously such things can’t be forced, but it would be great if more groups in the future made games that didn’t occupy the competitive arena space. We were quite surprised when we found out that we were the first cooperative puzzler team! It would be great if more teams tried super-wacky ideas (not to put down the other teams; from the team-based naval game to capture-the-farm I really loved the other games this year). Perhaps we could get a speaker to come and talk about game design? Not having experience with/time for game design seems to be the biggest reason why wacky games might not be coming out of CSE 125.

Q: Anything else?

Thank you Professor Voelker and Ruiqing for the best closing of our time at UCSD that we could have ever wished for!

Footnotes

Week Nine

It’s the time for polish! From awesome sound effects to crazy materials to not-running-at-10-fps this is the week where we work on making the game playable for other people besides ourselves!

We worked on sound effects and music, as well as how to actually integrate them into the engine (there was existing FMOD code in the engine prior to 125, but let’s just say it wasn’t exactly functional). We (and by we I mean Jeff) also worked on finalizing models, as well as adding materials to everything so that we don’t just see gray anymore! We also crafted (and built) one more final puzzle to flesh out the game. It’s less than five days to go, but we’re happy with our progress, and probably will only have to pull two all-nighters to finish things.

Here’s some of the audio we worked on:

Here’s some screenies and a video touring the facility with sound enabled (Mario and Zelda sounds will not be present in final game :S)

Team Reports

Bert

My goals were to fill in wherever necessary.

This week I designed and implemented two puzzles (the cargo hold, and the escape pod room), and made some changes to the AcvitvatorRegistrator to get their specific functionality working.

I accomplished what I set out to do.

Over this next week I plan to fill in wherever is needed to get the game finished.

My individual morale is great! Our game’s looking good!

Dexter

The focus this week is on tidying up the audiovisuals. I’ve been living in FMOD-land, having a grand old time playing with sound effects and music (no more collision code, yay!) Elton and I spent all weekend fixing Sound bugs (and a massive memory leak.) Jason did a fabulous job turning my voice into that of a melodic and smug AI.

We have 3D sound! Sounds are also arranged into channel groups, which allows us to lower the volume of a particular class of sounds while a really important one is playing (e.g. the AI on the ship taunting our players).

Jason and I created an ambient music track today in Audacity. Audacity isn’t exactly supposed to be used for this, but we made it work anyway, and we’re pretty happy with the results (https://clyp.it/bgiwmavt). The music is heavily inspired by Metroid games (specifically Metroid Prime and Metroid Fusion), and it loops cleanly without being overly obnoxious, which is really all we could ask for at this stage of the game. (Especially considering we are not really musicians…)

I love working on tiny little details that are barely noticeable, but improve the game as a whole. All of the lights in our scene give off a faintly audible fluorescent hum (turn up the bass d00d). I didn’t expect us to end up having a music track, so the lights aren’t as audible as they were before, but it really beats absolute silence. We don’t have a lot of objects that would passively generate sound in general, and I really want to take advantage of 3D sound wherever possible.

I also really like sound stuff, if that wasn’t obvious. By the time of the presentation, we’ll have all the placeholder UI replaced with something not-hideous, and our audio will be AWESOME. Time to get back to work!

Elton

This week I continued to work on the sound, to make it as robust as possible, and also to look at animation. Dexter and I came in on the weekend and fixed a crazy memory leak (9 GB!!!) while trying to work on the sound. We fixed it using git bisect which was pretty cool. And we fixed some bad FMOD code by making sure the 3D was working correctly and also so that we fixed the popping sound. Now the sounds are working most beautifully. Furthermore, after consulting some of the people who were working on this engine previously, we concluded that the animation would just work if we were to include them. I also recorded some sounds for the game and attended the voice acting sessions with Jason and Dexter.

I wish that we were at the point where all we’re doing is play testing, but unfortunately the map is still being constructed. So we will need to test later.

Last week… It’s the last week already… The goal of the week is to finish the game!!!! I actually have a lot of projects that need to be finished. I need to be on top of my game.

Jason

Hoo boy I’m really glad I used to do video editing for a YouTube channel with my friend. Otherwise I would have both zero experience with Audacity for sound editing and mixing, as well as Melodyne for autotuning. I spent a lot of time in both this week, recording Dexter’s voice and manipulating it to get the robot announcer voice depicted above. Definitely learned the limits of Audacity through this–due to Audacity not being a non-destructive editor with batching/layered effects, I spent a lot of time doing the same things over and over again. Ah well, get it done once and then get it over with forever!

I also spent some time helping Dexter with his ambient track. He had the base going, but I helped him with some of the effects (simulating spatial separation with reverb, playing with limiters) as well as adding the twinkly bits that intersperse with the alarm (or as Bert calls it, the whale noises). Lots of fun!

I also bounced around helping with some coding-related things (tuning up mouse movement, helping Dexter/Elton with sound code, helping Bert with level editor code). Not a ton of programming though, most of this week was sound editing.

This week I gotta finish the game, that’s pretty much it! I have some more sound work to do (including programming sound triggers), and I’m going to make it my personal goal to make the game “feel” good to play (when it comes to movement and such).

We’re going to finish clean! We decimated the big graphics issues, the big collision issues, and the big network issues. Things just work!

Jeff

My week this week was a rush to try to get as many textures done as possible, while also making sure that the game performed reasonably well. I finished textures for the security room, main corridors, armory (+ props), pod room (+ escape pods), and containers for the maze. I also modelled the connector from the corridor puzzle to the security room and made other minor adjustments throughout the map.

As far as programming goes, I found out now that we are using the entire map, that naively calculating shadow maps for ~50 point lights is a little bit slow (OK more than a little)… To try and fix this I added both light and object culling for shadow maps and reduced the number of lights. I also made several other smaller changes to fix bugs, tweak shading, and improve performance elsewhere.

This week I will finish the texturing, create the few remaining models, and help fix any last minute issues that come up. I am on track to finish everything that I need to and feeling good about the project as a whole too.

Pavan

Last week I worked on getting the master blender file to work correctly with all of the puzzles. I also implemented a crosshair that changed whenever the player looked at an object of interest. There were a lot of issues with linking multiple files through blender that I was eventually able to solve with Jeff’s help. For this last week, I plan to help finish the last puzzle to get into the escape pod room and put the finishing touches on our game. I feel good about the progress we have made last week and I’m excited to finish the quarter off strong!

Week Eight: No Time For a Clever Title

This week was primarily gameplay-centric. We tuned up physics a little bit more (you’ve heard that tons of times already), filled levels with props, colliders, and puzzle parts, started joining the levels into the whole map, and also started working on some stretch goals like sound and UI.

The pressure is starting to sink in now (we have to pull at least one all-nighter in the lab for it to be a true CSE125 experience, right?) but we’re hanging on.

Here’s some examples of what we worked on.

Team Reports

Bert

This week my plans were to basically fill in wherever needed.

I ended up helping debug/improve more collision response (of course), like fixing the player feet entering the ground, doing the downward raycasting from the player feet, so falling makes more sense, and getting the player and jump height correct. I also added box collides to a some levels, and got “splitting” doors working.

I basically did what I set out to do.

Next week I will design the next two puzzles, and continue doing whatever else needs doing (presumably helping run the beta test and fixing whatever comes up).

My morale is really good!

Dexter

I finally got a break from collision work. Earlier in the week I spent a great deal of time trying to minimize the likelihood that players will get stuck inside forcefields. Because the colliders are so thin for forcefields, it was sometimes possible for players to fall through the top of them and get stuck. There were several different approaches to solving this problem. After fiddling with the numbers and modifying some raycasts, I decided that we really ought to just make the force field colliders a little bigger, since many of the alternate solutions introduced new problems that were worse than the original bug. For the most part, it didn’t seem like players were getting stuck in the forcefields anymore, so I let it be (for now).

I did some Blender work with Pavan on Friday to prepare the armory room. I also went rogue and started building off the crosshair code to lay the groundwork for a rudimentary UI system (we really only have a loading screen, which is about the extent of the UI that we need anyway). We just need enough UI to have a semi-decent title screen, and I really didn’t want to see something like that cut. It just adds a teeny bit of polish.

I didn’t really see the point in working more on player movement issues until we can actually load in the entire level (or at least multiple levels). Once the entire level is in game, we can playtest the hell out of it and find where the actual game-breaking bugs are and prioritize those for the home stretch. By the end of this week, I’d like to have the game ready to playtest, so we can iron out as much as possible.

Elton

My concrete goal was to finish the sound over network. And I was able to accomplish the sound over the network after doing some weekend bug fixing.

The rest of the team is currently working on the level, the models for the levels, and other things pertaining to more of the gameplay oriented goals. Sound is more auxiliary as it only complements the gameplay. But bad sound design does ruin a game too. I still feel a little bit sad that we might end up abandoning the animations, because they are too hard to animate and the we might not have time to look into setting up the animations.

Next week, I want to help the team finish up making the levels and perhaps even merge them into the final game design. And perhaps even work on some sound effects.

Currently I feel pretty confident and the school year is winding down with no more midterms, so I can focus harder on this project!!

Jason

This week was a little slow due to my econ midterm.

I did some extra tuning to the input system I revamped last week. I also started adding more colliders to different levels, as well as hooking up game elements (and doing some debugging in our puzzle element hookup system). I also helped Pavan and Bert expand the puzzle element system (adding things like timed buttons and splitting doors).

Setting up the rooms takes time and isn’t very glamorous so there isn’t much to talk about. This week is going to be mostly that as well (although I might be helping Dexter create sounds/music for our game). I’m feeling OK.

Jeff

This week I spent once again primarily doing art. First of all, I finished modelling the connections between the various rooms. I modelled the room that houses the escape pods and a room for forks in the corridors and added more stuff to the overall level as well. I also helped people to get the levels set with the code for the actual puzzles. Finally, I finished up programming the crosshair. While I am apprehensive about the approaching demo date, I still feel good about getting everything done. Next week I will try to texture as much of the scene as possible and maybe add another room or two. I may also need to do rendering optimizations and bug fixes.

Pavan

My goals for the week were to continue to help building puzzles. I was able to finish the security room puzzle which included doing some additional work with pressure plates, chests, keys, and keyholes. I also helped to finish the prison puzzle. My goals for this upcoming week are to help design and implement the last two puzzles. Hopefully we will also be able to test what we have so far with other people besides us playing so that we can see where we stand compared to the average player of our game. I feel good about the progress we’ve been making but there is still a lot to do with only 2 weeks left, so we may have to put in some extra work to get things done by the demo.

Week Seven: Please take out your cellphones and vote for your favorite game title now!

It appears that even in week seven we can never truly escape collisions, whether they be with walls or our git commits. Regardless, walls of all orientations work super duper now, and even ramps (!!!) mysteriously ***just work***. We also implemented some more puzzle mechanics, started working on sound and animation support, and have customizable controller support working swell!

We’re already in the middle of adding colliders and puzzle elements to the rooms that Jeff has been modeling, and we’ll continue to do so next week (as well as yelling at Jeff whenever models that we all agreed upon like Week 4 suddenly don’t agree with our Week 8 mindsets). Looking forward to more video games! Also look forward to us naming our game, because we’re finally realizing that we need to do that…

Here’s some media of stuff that happened this week. Be sure to read the individual reports for more details.

Team Reports

Bert

My goal for this week was to work on the inventory system.

Instead, integrating the collision response with OBBs took much longer than expected so I mostly worked on that. Right now though, everything seems to work with OBBs!

I didn’t work on the inventory, but Pavan did that instead so it got done.

My plans for next week depend on if more problems come up in the OBB merge. If it works I’ll move on to gameplay logic.

My morale is quite good, got a lot done this week!

Dexter

Things slowed down for me last week. Merging the OBB code with our player movement script proved tricky. Before we had some hacks in the wall sliding code, and I had lots of trouble fixing the ray-OBB intersection code. What was working before for axis-aligned bounding boxes was fairly reliant on hardcoded normals, and since we wanted more flexibility with designing our levels, this would not scale.

I implemented multiple versions of the ray-OBB intersection (either by transforming the ray into object space, or performing the calculations in world space) and nothing seemed to be working. There was not one specific fix or breakthrough that really sealed the deal. Sometimes I had bad normals. I could be spotted in the lab mumbling to myself about vectors and pointing my fingers in odd angles in my efforts to affirm that my cross products were correct. Then I hit the dreaded curse of floating-point numbers and NaN. NaN is not nice. NaN is not your friend. NaN will ruin your day.

It was the last struggle in my seemingly endless quest to conquer collision detection. Finally, my nemesis is defeated. Incidentally, I had mentioned to Bert that by replacing our old hacky wall-sliding logic with some better (arguably simpler) math, we would theoretically be able to have ramps in our level. After all, if we can slide against diagonal walls by moving along the normal of the wall, and we can raycast efficiently in any direction, we should have no issues running up slopes if we raycast into the ground (which we were already doing so that the player can stand on the floor.)

Of course, the running joke among anyone who has ever written a platformer is that slopes never work. BUT GUESS WHAT! I tested them this afternoon on a whim, and (miraculously) they worked very smoothly. Since we still have a few more rooms to design and model, I’m hoping we can take advantage of this. For next week, I’ll be picking up whatever tasks are available.

Elton

My goal of this week was to send events such as Sound and Animations over the network.

I am still in the process of working on sound and I have postponed animations for now. I am not quite sure how Animations work and I might have to work with Jeff on it later who implemented the animations code.

Unfortunately, I was extremely busy this week. from an interview in Norcal to programming assignments and a midterm, I was not able to work on the project as much I would like. Next week I plan to work and finish the Sound code.

I just finished with one of the more difficult weeks of this quarter, and I am back and ready for action!

Jason

This week I worked on reforming the not-great input system that we quickly whipped up Week 1/2 in order to just get things working. Not only does it now properly sync with configuration-based system Elton worked on forever ago, but controllers now work awesomely, and you can swap between controllers and mice with no problems whatsoever. Unfortunately I wasted some time on this as I forgot to push my code before logging off, and ACMS loves to wipe the computers, which meant I had to implement this twice. It got done though!

I also got raycasting working with clickable objects, such as buttons and levers. With that example Pavan was able to get his key system working quickly. Finally just today I started adding colliders and gameplay elements (buttons, lasers, etc) to one of Jeff’s levels, the armory. The armory being surprisingly complex caused me to spend almost an hour just adding colliders that matched up with the level itself (essentially making an extremely low-poly version of the model to use for speedy collision), so I wasn’t able to hook up the buttons and the lasers by today. But now that I’m more up-to-speed with the process in Blender (plus other models appearing to be much less complex) this means that further setups should go faster.

Hooking up levels and testing them in the game engine is going to be most of my week this week. We need to at least get basic colliders up ASAP so we can tell Jeff if a particular room feels too big or too small when actually moving around inside (especially as there will be up to four players in a single room).

I’m feeling OK, but this Friday is a midterm for a class that I’ve been 110% neglecting to put effort into 125 (I did it for you guys!!) so I might have to peter off near the end of the week to study for that.

Jeff

This week I once again spent a large portion of my time doing art. I finished up work on modelling the armory and the hub security room. All that they have left is to arrange the puzzle props and to texture them. I also made progress on the cargo hold, connecting all of the different rooms together, and tweaked some smaller props. On the code side of things I started adding in a crosshair for selecting things and fixed some small bugs. Next week I will once again be doing lots of art, as there is still tons that needs to be done for the finished product. I will also finished up on getting everything loaded as a game on the code side rather than just individual rooms. I am still feeling good about finishing everything that I need to and the group as a whole finishing the game, although I am unsure if we will get to many stretch goals.

Pavan

My goals for the week were to fix a dead client bug, and to help Dexter with a crosshair that changes colors based on what the player is looking at. I was able to temporarily fix the dead client bug, but I and the others think it was due to a race condition that we were unable to identify. Just by calculating a checksum and sending it across the network with each packet even if it was not actually used, “fixed” the bug. Until we figure out the true source of the bug, I’ve left this code unmerged. Apart from that, I switched objectives from working on a crosshair to doing more gameplay development regarding chests, keys, and a player inventory. I successfully implemented this in such a way that just by naming the objects a specific way in blender, they just work when you load them into the scene that the player is in. You can see this in one of the screen recordings I posted.

My goals for next week are to work on building more puzzles in blender and hooking up all of the activators to their targets so that we can test out more puzzles.

I feel good about the progress I was able to make this past week, and can’t wait till we get our puzzles linked together so that we can play them!

Week Six (Now Free of Game of Thrones Spoilers!)

See that mountain over there? You can’t walk through it.

That’s essentially the crux of our week. Bert, Dexter, and Pavan came through and gave us working wall and floor collisions. They work pretty well, and the players can even jump on top of each other (it’s kind of buggy though). We also worked on furthering our puzzle creator system, trimming the fat when it comes to game design, and Jeff is now considering a minor in ICAM given how much Blender he’s been doing.

It’s all downhill (i.e. gameplay programming) from here! The infrastructure needs some final tweaks to get things perfect, but we can finally say that the engine is done! This is an engine programming class, right?

Here are some images of stuff that happened!

Team Reports

Bert

My goal for this week was to get collision response working.

I got it working! Me, Dexter, and Pavan teamed up and fixed some bugs in the ray-casting to get the wall sliding working. I also got the jumping working, so the players hit their heads on the ceiling, fall off of ledges, etc. This basically makes the first two puzzles fully playable (presumably other folks have screen shots of it?).

My specific goals for next week are to get the inventory system and “chest opening” working.

My morale is great, I put in a bunch of hours and got a lot done!

Dexter

Sorry, but no poetry this week. I’ve finally finished our collision system. It only took six weeks to get here. Oriented bounding boxes collide with each other properly, and in Release mode, I’m maintaining a pretty high frame rate. The octree I spent so much time implementing is paying off, and I’ve learned a whole lot in the process.

Last week I also spent a little bit of time exploring our particle system, and modified our object loader to parse particle definition files and place them appropriately in the scene. Emitter loading works quite well, but I couldn’t for the life of me figure out why no particles were actually drawn, despite the emitter object being properly placed and initialized. Because the team was really waiting on my collision code, I decided not to invest more time investigating, but I’d really like to get to the bottom of it. Our renderer is gorgeous as is, but you’ve GOT to have particles.

Pavan and Bert managed to get player-player collisions working well with axis-aligned bounding boxes. It was definitely a boost to our morale (in that we’re one step closer to actually having a game) and mine especially, since I’ve been struggling to get the collision system usable enough for gameplay.

Next week’s goal is to flesh out the gameplay. Implement more puzzles, get the player’s crosshair working properly when raycasts intersect interactable objects, and to assist anyone who needs to use the collision system. I’ll be picking up any miscellaneous tasks as needed, and fixing critical collision bugs if (when?) more arise.

Elton

This week my goal was to increase the robustness of the Activator Registrator system that was Jason created. Also I wanted to figure out what was going on with the client bug in which when loading 4 clients on the computer, clients would some times gray out and not start.

I was able to increase the robustness of the Activator Registrator with a more generalized version of parsing the naming schema which maps the targets to activators and vice versa. Right now the general framework is set up to be able to parse more complex naming schemas.

I was unable to figure out the the graying of the clients, and Pavan said he would look at it later this week. This might be a show stopper if it appears near release, so it would be very helpful to find it soon.

Next week I will continue to increase the robustness of the Activator Registrator system so that when we implement gameplay, we just have to worry about the naming the blender files. I am also thinking about sending events over networks which will include the sounds. I will be out of commission on Thursday and Friday as I am heading out for an interview.

This week is particularly tough for me and I am feeling really tired. I want to work more on the project but my other commitments are preventing me from doing so. I am doing my best to work on it.

Jason

This week I worked on fixing some basis things we relied on, such as player movement. The script I wrote forever ago was very hackish, and made certain things more difficult than they needed be, so I reworked a lot of the FPS controller (fixing a rather nasty bug in the process). I also helped Elton further extend the Activator Registrator, making the system a good bit modular than it was before.

I also worked on using Dexter’s Raycasting API to allow pressing on buttons and levers. While this works fine (hard to tell but I am indeed clicking on that button in the GIF above), it really made be notice the also rather hackish and inflexible way we were sending Input data over the network, something we also did very quickly at the beginning in order to just get things going. I’m going to work on fixing that now, as it makes certain types of input events (such as clicking or jumping, essentially one-time, edge-based actions as opposed to continuous actions like pressing forward) really difficult to do. It’ll also give us much better controller support than what we have now, which is what we want to do.

Finally, others have agreed to add more puzzle components, so I’ll be briefly helping them with how to use the Activator Registrator system.

I’m feeling OK at the moment. I didn’t get as much done as I would have hoped last week (Overwatch open beta ;_;) but now that collision is done (I feel like I’ve said that several times now, hehe) puzzles can be directly tested in actual context, which should make development soar. Not looking forward to diving back into networking code for the Input system though…

Jeff

This week I focused almost entirely on art, which is just about what I was expecting to do. The main pieces of it that I worked on this week were creating the base room models for the armory and cargo hold. I also worked on several smaller props such as modelling a chest and texturing the pressure plates.

Finally, I figured out and set up a workflow to combine all of the individual pieces together into one large master scene file. Other than art, I made some small improvements to the object loader and fixed a number of bugs throughout the game.

Next week will again be largely art, plus possibly doing some basic UI programming. In particular, I hope to finish up the props for the rooms that I have already modelled, and texture the security room. I am feeling pretty good about where we are in the project and am looking forward to finishing up the game.

Pavan

Last week my goals were to implement respawning, which I was able to accomplish, and help with wall collision and jumping. Dexter and I were able to help Bert complete both wall collision and jumping so that we were actually able to play our first puzzle through.

My goals for next week are to help Dexter with a crosshair that changes color based on what objects you are looking at. I also will be working on fixing a bug that we have in which clients don’t load fully. It seems like they aren’t receiving all of the data over the network that they need to, so I will probably look into the networking code first to see if I can figure out what is going on.

I feel good about the progress we are making and it was cool to be able to actually play our puzzle last Friday when we finished jumping. We just did a re-prioritization of tasks which also makes me feel better that we will be able to finish on time.