This is a “game lab” entry of my Game Studies class, just in case anyone else is actually reading this. I played 3 games and observed two of them. One was a two-player game.
The first game was “There is only one level.”
This was an interesting game that was reminiscent of my first few times attempting to make 2D platformers. The challenges involve breaking the controls without telling you exactly how, which made the game play like a hilariously bad platformer at times. The challenge of playing with the controls made it fun though.
The next game I observed my buddy play Canabalt, a auto-sidescrolling 2D platformer that made a lot of fuss when it first came out. The game involves pressing one button to avoid procedurally generated obstacles. I was delighted to see that my buddy was very bored by the game. The game is praised for its simplicity, something I don’t find worthy of praise. However, I will praise the game designer for getting so much for so little work.
Third, we played SJSU’s very own Clashing Code, a 2D fighting game that is mix between Smash Bros and anime/airdasher games, a wonderful combination. Few online flash games get fighting game mechanics right, but this one succeeds in being unique while adhering to the genre’s core mechanics that are important for getting the right feel. Me and my buddy had a blast playing it, and other groups took notice.
Fourth, I watched my buddy play Park Racer, a generic racing game. He had trouble controlling the car, and I could tell why. There’s just no way to have good control in racing game without having some form of analog control, like an analog stick or driving wheel. With digital controls, you have two choices. One is to have only one turning speed, and the other is to have only one turning acceleration. One turning speed is obviously bad, as you’ll be limited only one turning angle. With constant turning acceleration, you’ll be able to make small adjustments easily, but turning sharply takes time and it is difficult to stop turning, and it’s very easy to over-correct if the acceleration is too high, while it takes too long to react if too slow. This is a common issue I see in games with acceleration. They are overly simplistic physics models that aren’t quite right realistic and somehow result in over-sensitive and under-sensitive controls at the same time. The solution here is to have non-constant turning acceleration, but I’ve ranted long enough.
The last game was Myxa, a very basic 2D platformer made in Game Maker. Once again, I saw common pitfalls. First off, the collision system wasn’t quite right, and I could tell that they used a similar tutorial that I did, but didn’t fix the problems that the teacher purposely left in for people to solve. The game checks horizontal and vertical collisions, but doesn’t correct the player’s position unless their vertical velocity would imply a collision on the next frame or if their horizontal velocity would imply a collision on the next frame, but not both. So, you can get stuck by jumping diagonally into the corner, since there’s nothing directly below you or to the side, so the collision doesn’t trigger until the next frame when you’re already partway into the tile. The hitboxes were also wrong, too. The character was a minimalistic round ball creature, but its hitbox was square, with corners extending past the sprite. If you don’t want to piss off your players (for good reason), you need to inscribe the bounding rectangle inside the sprite, not the other way around. However, the game was still fun because it was hard.