616 Trinity
Whew, this game was a lot of work. It was a school project where we got into a team and made a game over the course of a semester. We had 3 programmers, 2 artists, 2 designers, and a designer/producer.
Our initial plan was to make a simple engine and use that to make a very simple point and click game. That was denied, and we had to use another engine. Since we were now using Unity, we were able to do much more than we originally could. We expanded the point and click to try to make a game more like Amnesia. Unfortunately, we ran out of time and weren't able to really add that scary mood to our game.
So what did I do on this project? I was in charge of completing three of the six puzzles. I implemented most of the physics stuff; things like opening and closing doors, drawers, picking and throwing objects (These were the most fun to work on). I worked on the pause menu, a lot of the crosshair stuff, and also put most of the sound into our game. Later on in the project, I became the art tool; taking the artists models and textures, and putting them into the game and making prefabs of the models. This was probably the worst part, because links were always broken (missing materials or models) when I uploaded them to Perforce.
The first hurdle we had to overcome was having three programmers. We had all programmed games by ourselves, and only had a little experience working on the same project with another programmer. We needed to find a way for all of us to work on the game at the same time. We found a way to integrate Perforce into Unity and went from there. Of course there were times where someone had made changes to something someone else was already working on. Overall, though, this helped us a ton. There would have been no way we would have been able to do what we did if it wasn't for Perforce. Everything worked pretty easily with Perforce, except models. For some reason, they always had broken links.
Probably the hardest thing that I did was get the electric puzzle to work. It was basically a pathing challenge: get the electric to follow the current. It was tough because the pieces could be rotated, and I had to make sure I covered all the places that the electric could go. The day of the project's presentation, we found that it didn't work completely: the electric could go in an infinite loop. Instead of fixing the problem, we just designed around it; not much else we could do in the short amount of time that we had.
The stuff that we were able to pull off was cool, but it is not much of a game. I feel that we scoped it a bit too large, and didn't have much time to polish up the game – we barely finished it. When I was coding, I really only had enough time to get it working. If I have the time, I usually like to make it more readable and usable after it just works. I certainly didn't have that time on this project.
Another interesting thing about this game was it was the first game idea that I worked on that I didn't come up with. It was a lot harder to work on the game when I didn't know exactly how it worked. A lot of the thinking was done by designers, and I was always asking them how things worked. It was certainly a learning experience for me.
A cool bug we had very late in the development: picking up the physics objects, and having them fly to some location. At first we just thought someone didn't update something. Then we found that it only happened when you played the game through the main menu instead of starting in the level. We had to change scenes to get from the main menu, so that narrowed it down a bit. I figured something had to not be getting set right, even though it loaded a different level. Turned out to be a static variable for how you should take your mouse input, having it move around the screen in 2d or actually rotate your camera. It was pretty strange, but I was able to figure it out.