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.

https://gyazo.com/0ec2dae7abd2b8dda64480722ef3b4d7

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!