And so began the work on "Game":
Bugs did crawl (twas kind of lame)
And though a raycast rework brewed,
Our merging process remained shrewd.
Beganeth a trial of walls and rays:
Which absorbed the time of many days,
And though my octree builds were slowing,
No team was blocked: our features flowing
The collision system needs more tweaking,
It works, but Bert would like to do some peeking,
Into things like normals, which he needs
To slide against walls with grace and ease.
Oriented boxes are the next request,
No breaks for me, I shall not rest!
We've built one puzzle, more on the way.
At least we've got a game to play.
—Dexter Friedman, Deceleration!!Structured
This was the week of video games! We finalized our network transmission system, further optimized and extended our collision system, worked on collision-based movement, and implemented a basic puzzle creation system using Blender as our level editor of choice (OK, most of us didn’t choose Blender, it was just sort of forced upon us).
Here’s a shot of what the wireframe box colliders look like in that awesome hallway from last week! Hopefully we’ll have time to show you this cool hallway in action tomorrow.
Here’s a donut that spins if you step on a pressure plate! It’s hard to see in the GIF but there’s another cubeman in the background stepping on the other pressure plate.
My goal for this week was to get it so that the player could collide with walls.
I was able to mostly accomplish this using a couple of methods, but neither would have worked well for the final game. The first one I tried was the “bounce” method where, upon entering a wall, the player would be “bounced” back to the location they were at before the
collisionEnter. The problem with this is that, while it mostly worked, sometimes they would not successfully exit the object (despite being in the location they were at before they entered), and would therefore be able to “slip” inside it. This may have been related to floating point precision? I was able to fix this by bouncing them back further, but this created an unacceptable “jitter” that was very noticeable and would have been bad to leave in, especially as the player will be constantly colliding with floors.
The next plan was to use raycasting to slide the player along walls (probably using this method: http://www.gamedev.net/page/resources/_/technical/game-programming/general-collision-detection-for-games-using-ell-r1026). However, raycasting wasn’t working until Sunday so instead I tried messing around with other methods in case we couldn’t get raycasting working. On Friday I was able to hack together a method to prevent the player from moving towards the collider’s origin as soon as they collide. However, this had a lot of corner cases where it didn’t work well, so now that raycasting is implemented I’ll abandon that line of work and focus on the original plan.
This coming week I will implement the method described above, and then move on to getting the levels we’ve designed in-game.
My individual morale is quite good. While my attempts this week ultimately failed, it wasn’t for lack of trying. I was able to spend quite a bit of time on 125 to make up for my lack of contribution the week before.
Editor’s note: I didn’t *force* Dexter to write a poem, I just gave him an offer he couldn’t refuse.
One of the concrete goals for the week was to get a preliminary puzzle working and continue to increase the robustness of the Network code.
I continued to increase the robustness of the network code and added support to more components to them. Now Lighting component data is being sent over the network.
Right now we are all still completing core functionalities of the code. Jason is working on his “Activator Registrator” which logs events that can be used to make switches, pressure plates, and other things that trigger switches.
Furthermore, Dexter is merging his raycasting into develop branch. Once these things get added together, we will begin working on the gameplay and implement our puzzles. As I am typing this, we are currently implementing the first puzzle with the Activator Registrator.
Currently I am feeling OK in terms of morale. My other school work and commitments, however, are beginning to pile on. Since we are on the verge of moving from Engine building to game making, I am feeling excited.
Say it with me,
We’re getting to a point where we can finally start working on gameplay, and a big part of that is actually creating levels. Jeff’s done a great job of physically modeling levels, but how do we actually hook them up to be interactive? How exactly does that lever on the wall open that door?
This week I worked on being able to use Blender as a level and puzzle editor for our game. Essentially, we have two types of objects, Activators and Targets. Activators are like levers, buttons, pressure plates, or even esoteric things like timers. Targets are things that are activated, such as doors, chests, gates, lasers, flying death traps, spinning monkey heads, etc.
I worked on making it such that if you name objects in Blender a certain way, in a preprocessing step the game will automatically connect all Activators with their specified Targets using scripts that we write through the power of interfaces; there are literal
Target virtual classes that have base functionality written (i.e. they know how to connect to each other, and how to send activation events between each other). You then write components on top of these that tap into their events, and boom, you have a modular, extensible puzzle creation system! It’s magic!!
I’m feeling good! This week I’ve settled into more of a managerial role, doling out tasks to everyone and prioritizing priorities. I’m also proud to say that less than 5% of my workload this week was networking code! Woo!
This week I did not accomplish as much as I would have liked because of midterms in other classes. While I had intended to help to get the first couple of puzzles working, I was not able to do very much there. What I did do was art and many smaller changes to the engine. For art, I textured the prison starting area, and created models for buttons, pressure plates, and levers. I also improved object loading to be more flexible and fixed some bugs. For next week I am going to mostly focus on art as well as small improvements to the core engine that make other people’s jobs easier. My morale is lower because I didn’t do much this week, but that should hopefully improve now that I have more time again.
My goals for the week were to add some logging to the network code so that in the future we could view certain stats about the network while we play the game. I also wanted to help complete the first puzzle by making sure all events were broadcasted throughout the network properly.
I was able to implement some basic logging when the “n” key is pressed on the server to see the breakdown of bytes being sent to all clients. I also implemented a client connect retry mechanism that would try to connect to the server for a configurable amount of time before giving up and exiting. I was able to help send camera data and active/visibility data across the network so that when Jason finished his work on plates, he would have a simple API to call into in order to activate/deactivate the lasers in the puzzle.
I was able to meet most of my goals this week but I did feel like I had a good amount of idle time. I spent this time by going over the Engine code so that once collision detection was working properly I will be able to help with gameplay logic. My goals for next week are to start working on gameplay logic, while continuing to send whatever data is necessary over the network. I feel like this week was a little slow for me, but I can sense that it will pick up very quickly and I want to be ready so that I can help with a lot of gameplay features in this upcoming week.