Creating a Masterpiece: Testing and Learning

Posted on

You could assemble a team and create a game with amazing art, animation, sound, gameplay and so forth; to actually take all that and balance everything into an enjoyable and interesting game? Well that’s a talent in itself. Every game needs someone to put it all together, someone to organize, balance, and direct the talent into making something truly inspiring. This is what the legends do; Todd Howard, Hideo Kojima, Shigeru Miyamoto. This is what I am trying to accomplish.

Doukutsu Monogatari, better known by its English name, Cave Story, is a freeware platform adventure video game released in 2004 for the PC. It was developed by Daisuke “Pixel” Amaya over five years, in his free time. He wrote tools to create levels, audio, and more just for Cave Story. Pixel created all the assets, gameplay, and design. Cave Story really does it well, and is one of my inspirations for programming and design in general. Between the aesthetic, tight responsive gameplay, and overall quality, this game made by one person in his spare time is a very good game to say the least.

Now let’s get a bit technical. In order to make a good game, I’m going to be taking a look at what makes other games so good. We’ll start with Cave Story, as it isn’t very complex in its design. As seen in this video of Cave Story’s beta, as seen here, the game clearly uses a Tile Map based system. A very popular mechanic used throughout 2D games in the pre 3D/N64 era. This carries over into the final release, but features ramps and other variations in terrain to spice up the environments. This makes for easy and quick map creation, as well as reinforcing the retro aesthetic. Amaya did this probably by a simple 2D array packed into a 1D array. Just to save accessing time and memory. Mario Bros used this, as with many other popular platformers.

Another mechanic in Cave Story is the physics. This is seen throughout the jumping, particles, enemies and other objects effected by it. Person over on the Cave Story forums has done some in depth research on the topic and I will be referencing this post Cave Story purposely creates floaty jump mechanics to reinforce other aspects of the gameplay. This is done through both the player character and the Camera itself. The Camera in Cave Story has both a Camera Position and a Target Position. It then Focuses on to the player using this block of code here:
CamPosX += (*FocusX - 0x14000 - CamPosX) / FocusSpeed;
CamPosY += (*FocusY - 0xF000 - CamPosY) / FocusSpeed;

This takes the Camera Position and with a slight delay moves it towards the target position, getting slower based off how close the camera is. And if the focus speed was one, then the target position would always be in the center.

As for the Player’s movement itself, Pixel uses very simple code that just adds the velocity to the player’s current velocity and then updates the player in the game world based off of its current velocity. Amaya utilizes if statements to make sure no maximum velocities are exceeded. Even though all of the characters movement code is very simple, it feels very fun and floaty making the game more enjoyable. And the gravity part of the physics is just this:
if !jump_key_pressed || (current_velocity_y < 0) current_velocity_y -= Gravity
What do we take away from this? Using simple code, you can make tight responsive controls, and fun gameplay that will cater to all types of gamers. Because sometimes you have to stop and ask, Is what I’m about to add going to make the game more fun or more realistic. But hey, it all depends on what your game is trying to accomplish. Thanks for reading.

Leave a Reply

Your email address will not be published. Required fields are marked *