Carl Eats Sheep was made for my Game Technology II class as the final project. In Game Tech II, I learned how to write in C# and make game in a 3D space in Unity for the first time. The final assignment was to make a full gameplay experience or vertical slice using only things that we had learned how to do in the class. Having worked with pilot controls in the class, my team and I decided that turning the classic video game, Snake, into a 3D experience would be an interesting challenge. Our professor, Guillaume Langlois, loved the idea and sent us on our way to make it. Our team composition was a problem initially, having no specialized artists or programmers to work with. In the end, we found that we worked very well as a squad, each having our own, different strengths that helped bring the project together.

I handled all camera work, menuing, skybox and music switching, all sound engineering, sheep physics and spawn systems, and UI.

This arcade-style game's objective is to eat as many sheep as you can, and avoid crashing into the play boundaries and the player's own body. In eating sheep, the dragon the player controls gets faster and longer, making it harder to control and giving the player more obstacles to avoid. This system makes moving around the atmospheric setting more difficult and exciting over time. When the player eventually crashes, every segment of the dragon's body explodes and is tallied up as the player's score.

The main challenge for me to figure out while developing this game was the camera system. Being able to move and rotate the camera in all directions to always have a good view of the dragon was difficult to pull off. It still is not perfect in its current state, but works well enough. If I were to change one thing about the camera in this build it would be where I have the camera focusing. In developing Planet Snatchers and Keep On Rolling, I learned that the camera can be positioned in a way that can give the player move room to look at where they are going rather than so much focus on the player character in the center of the screen.

Even though the game is pretty simple, I am proud of the amount of polish my team and I were able to put on it in only 4 weeks.

Keep On Rolling is a solo project that was made in my Spring 2017 semester Advanced Seminar class, in which I saw an opportunity to hone my abilities in level design. On the first day of class, I proposed that I either create a Super Monkey Ball clone, or mod Super Monkey Ball 2 and create a magnitude of unique levels to make a fun to play yet challenging difficulty curve. My professor, Ben Wiley, thought this was a good idea citing it as a perfect opportunity to also get even more accustomed to an iterative process.

Super Monkey Ball is a game in which you tilt a level to move your monkey-in-hamster-ball-character to the goal of each level. Keep On Rolling, being heavily inspired by that series, stuck to that formula. During the span of the class with critique and feedback from my peers, the game became more than just a clone with the introduction of new mechanics and a ranking system that encourage players to aim for better times on each level. The new game mechanic that I introduced were badges that give you an additional ability in the level when you collect them. The two types of badges that can be used are the Jump and In-Air Jump badges. These two pick-ups add a whole new level of platforming to the Super Monkey Ball formula that is interesting to long time players, and makes some tasks far easier for newer players. The ranking system includes the display of the fastest time on the menu, a medal for clearing the level, and a medal for completing the level in a par time.

The first thing that I set out to do in this project was to research the difficulty curves of other games and evaluate how fun, frustrating, or boring the games were because of this. To evaluate this I would play through the game under examination, marking down the difficulty of moment to moment gameplay throughout the experience. The first of the two games I looked at was Super Monkey Ball 2. I had played the game before so I was taking my ratings with a grain of salt. I evaluated the difficulty of each individual level of Super Monkey Ball 2's story mode to see the curve. This curve can be seen below. In reviewing this curve and reflecting on my feelings during the play sessions, I found that Super Monkey Ball 2 had a pretty brutal difficulty ramp, always giving the player a challenge that rivals the last. This difficulty ramp did make completing every single level very rewarding and give me a sense of accomplishment, which I would want to give players of Keep On Rolling.

After finishing my first difficulty curve, I thought it best to play a newer game that I had not played to be able to see how two totally different games go about difficulty ramping. I choose to examine Shantae: Half-Genie Hero. I found this game to be a fun, easy-going experience where I was challenged at roughly the same level throughout the playthrough, the exceptions being the final level and boss battles. From this, I learned that giving the player breaks in high-stress, high-difficulty moments makes it easier to play in longer play sessions and makes overcoming tough obstacles more rewarding rather than being a grind.

So, from what I had learned from the playing these two games, my difficulty ramp aimed to be challenging, but offer stretches of levels where the player could take it easy and not try so hard to complete the level. In doing this, I hoped to keep players playing for a long time, keep them challenged, and keep them from quitting due to difficulty.

The movement system featured in Keep On Rolling was supposed to be easy to make and simple so that I could begin making levels right away. I wanted to emulate Super Monkey Ball's movement style of tilting the stage to move the ball. When I began work on this system I tried to emulate that. I thought a lot about how this would work and made a document outlining how the stage must rotate with the player as its origin so that the ball would not be flung off into space. It was a simple enough concept, but after working on it for about two weeks with different approaches, all of them had terrible drawbacks and problems. My next thought was, "If I can't make it work for real, why not fake it working?"\

The current movement system simply applies forces to the ball to move it according to the camera direction. However, there is an illusion of the stage tilting given by the camera which tilts and sways based on the direction the control stick is being held in. The illusion was good enough to fool almost every new tester on the game. The first few weeks with this system was hard on players because the camera rotations were to jittery and nauseating. After careful tweaking, the camera is convincing yet subtle enough for players not to bring it up. About half-way through the production of the game, I realized that a lot of problems players were having with gauging distances was at fault with the camera. I refocused the camera so that instead of showing the screen 50-50, in-front and behind the player, it shows more of a 80 ahead- 20 behind split. This change reduced foreshortening and players were more naturally able to judge distances.

After the movement system was in place, and somewhat finalized, I got to work making levels. I made around 5 levels at a time in groups introducing certain mechanics and letting players get used to them, then testing what they had learned in the following set of levels. So, the level groups I made were 5 introductory movement levels, 5 challenge movement levels, 5 jump-badge introductory level, 5 jump-badge challenge levels, 5 in-air-jump-badge levels, and finally 5 in-air-jump challenge/mastery levels.

In creating each introductory level, I wanted to show the player different ways they were expected to use new mechanics in a low-risk environment. In creating challenge levels I wanted to challenge the player's understanding of the previously introduced mechanics in new ways that will make them think about a good way to finish the level as well as execute well on those ideas to make it through the stage.

Much of the time when creating a level, that level would be too difficulty for the point in the difficulty ramp that I was aiming for. I tested and iterated upon the sets of 5 levels I was making for up two weeks straight trying to fine tune them to the desired difficulty. Many stages had to be tested even more than those two weeks to get to a nice state. Many "problem levels" that testers would repeatedly complain about or struggle to get past received loads of iterations. Some levels, such as ones with ramps, needed to get cut because all of the changes made to them never fixed the problems with them. However, the replacement levels proved to be very fun for testers and ended up hitting the difficulty ramp I was looking for.