Free the Frog

Free the Frog is the game that I developed for Ludum Dare 37. Help the frog escape so he can make the leap home!

Post Mortem

Ludum Dare 37 was the twelfth time that I competed in the 48 hour game development competition. I wanted to create something with gameplay similar to the classic arcade game Frogger.

The trick with this game was getting the movement controls right. I wanted to make it so that you could press the gamepad in a direction, and the frog would immediately move to the next “square”. Therefore, the movements were discrete, so I could not use my typical methods for doing continuous movement. The area where the player can move can be thought of as a big chess board. When a direction is pressed, the frog’s location (a row and column stored as integers) is updated. Then, the frog is pulled to that new location. I had to add a boolean variable to track if the frog is moving, so that no new input is accepted until he reaches his destination. This type of movement is great for a game like this, because the player can clearly see if they will avoid an obstacle, which eliminates any case for bad collision detection.

I wanted to have a lot of mechanics in this game, which have been lacking in my previous game jam games. I wanted each level to introduce something new. I got this idea from watching Super Mario Bros 3 videos a few days earlier, where each level had some new mechanic or concept added.

The first level just introduces the player to the game, so the player just has to maneuver around the board to reach the exit.
The second level introduces the guns, which is the first time that the player can actually lose a life. The guns only shoot one bullet at a time and can be easily dodged.
The next level reuses the gun that I created, but this time it shoots three bullets in a row. It’s a nice way to create a new obstacle with minimal development effort. Using Playmaker makes altering the standard gun relatively simple.
The next obstacle introduced is the spikes. I think the first spikes may be a little unfair, because they start hidden and pop up right as the player is moving through the game level. If the player looks closely, they can see the tip of the spike when it is down, but maybe there should be some other visual cue. I used a simple Blender cylinder and moved the vertices at one end together to create a cone. I used Playmaker to move the spike up and down, waiting for a few seconds after each position transition. The frog is killed when it collides with the collision box around the spike.
Moving spikes surrounding a warp area
There is one beneficial power-up in the game. I think one of the flaws of the game is that there are too many negative obstacles at the beginning, and not enough things to benefit the player. The speed booster power-up decreases the amount of time that it takes to move to the next square. I put a long row of spikes, which makes it necessary to use the speed booster to pass. I used trail and error to determine how many spikes would be required in order to have to use the speed booster. Unfortunately, only one level uses the speed booster power-up, so I would have also liked to use the speed booster in another level.
Another object that the player can interact with is the warp object. I made it so that there are two varieties of warp points, one red and one blue. The red warps to the other red point, and the blue warps to the other blue point. On the first level with warps, I made it so that red warp is easily accessible and the blue warp is surrounded by spikes. If the player takes the blue warp, then the exit is easily reachable. If the player takes the red warp, then the exit is blocked by spikes. It seems to be good game design to reward the player later if they choose the more difficult path first.
The remaining levels don’t introduce any new obstacles or powerups, but I tried to make them unique by using different obstacles together to make a unique challenge to reach the exit. The seventh stage is probably the most difficult, where the player must move at the exact time to avoid the combination of gun bullets and spikes, which move at different rates. However, I had to ensure that there was a small period when the path was passable, to ensure that the level could be completed.

For the graphics, I used Blender as usual to model, texture map, and animate the frog. However, when the frog dies, I used the cell fracture plugin for Blender to make an animation of the frog falling apart into pieces. This effect is probably more suitable for non-organic objects, but I liked the effect so much that I had to include it in this game.

As for the music, I used GarageBand on my Mac Book Pro again for composing the music. I didn’t do anything really out of the ordinary. I used the drummer track to lay down a unique beat. I made a couple of melodies, which I alternated and swapped instruments. Sometimes I would slightly modify and mix the melodies to keep the music interesting. The music for the game level is one minute and twenty eight seconds, which I think is the right length for it not to be too repetitive. I did a few quick searches for classic game level songs, and most songs seem to be around 90 seconds to two minutes before they loop.

As I did for my last Ludum Dare game, I used text files for storing the level layouts. Each character in the file represents either an object, obstacle, powerup, warp area, exit, or starting position. The text files are assigned to TextAsset objects in Unity, and then parsed in my game code using the Split and ToCharArray methods. The text files are stored in the Resources folder in the Unity project, which makes them accessible to the C# script. One issue was that I had to also encode the direction the guns were facing, because they could face either left or right. Having a gun facing right on the right side of the room would be pointless. Therefore, I used a capital letter if the gun is facing right and a lowercase letter if the gun is facing left. Ideally, the game would have a level editor, which would store the level data more efficiently. However, levels can be created and modified much more quickly by using a text editor, which is a big plus for a two day game jam.

There were some things that could have went more smoothly while developing the game. I forgot that when you call Destroy on an object, it doesn’t actually get destroyed until the next frame. So trying to do a while loop to delete all children objects while the number of children is greater than zero will result in an infinite loop and crash Unity. You would think by now Unity would give the option to break out of an infinite loop without crashing and losing all of your work since your last save. There was actually a way to attach the process to the debugger in the IDE and set a breakpoint and mess around with the variables to get it unstuck, but that method is very convoluted and probably wastes more time than just restarting Unity and losing whatever progress you’ve made. There is an editor script that automatically saves when you press play button that goes in the Editor folder, so I should remember to always add that script when creating a new project.

I didn’t care much for the Ludum Dare 37 theme “One Room”, so I made the story explain that the frog is stuck in one room. When the frog reaches the quantum accelerator artifact, then he is warped to the same room in a different time and dimension, which is why the room changes every time. I actually based the story on the opener from the 90’s television show Quantum Leap. The idea of the room changing each time probably came from my years of playing Castlevania, where it’s the same castle in every game but configured differently for every game.

I have a few ideas on future additions to the game. The bland gray background should be replaced, and it would be nice to have water filling in the empty areas around the blocks. The individual squares could be replaced with lillypads that the frog can walk across. The game could also benefit from more levels. The models and texture maps for some of the obstacles, such as the guns and spikes, could be improved as well.

Released January 30, 2017January 30, 2017

Ichiban Sokoban

Ichiban Sokoban is a sokoban game that I developed in Unity. Use the robot to push the crates into the goal areas. Try to finish the levels in the lowest possible number of moves. If you get stuck, you can reset the level and try again.

Developer Log

I developed Ichiban Sokoban for the Mini LD #67, which had the Classic Mashmix theme. One of the suggested games to remix was Sokoban. I had developed a sokoban game years ago in Java for a college course.

I started developing the game by creating a simple Board class in C#, which basically just held the textual representation of the game (I changed the chars to ints for simplicity). When the player presses an arrow key, it updates the Board, not the game world.

I created another class that actually handles instantiating all of the object in the game world. When the Board object is updated, all of the GameObjects in the scene update their positions according to the board. None of the GameObjects in the world have colliders.

The game can parse levels in the standard sokoban text format. I’m hoping to write a file importer so that players can load their own levels.

I’ve been developing Ichiban Sokoban on the nights and weekends for about two weeks now. I’m really happy with what I have developed. The game seems to be received well on GameJolt, as it has quite a few downloads for a desktop game and some positive votes.

I got the file importer working, which reads out of the default application directory using the Application.dataPath variable, with “/maps” appended. I had to write some extra code to verify the the file extension ends in “.txt”, otherwise it will try to read the “.meta” files that Unity adds by default.

For a Windows build, the “maps” folder must be placed in the IchibanSokoban_Data folder. For a Mac build, the “maps” folder must be placed in the “IchibanSokoban.app/Contents” folder. On MacOS, you have to right click the folder and select to show contents. Otherwise, double clicking the IchibanSokoban.app folder will start the game. It is a hassle since on both platforms, the “maps” folder must be copied every time the package is built, since it deletes any folders that already exist there. I should create a script that automatically copies the maps files after a build.

I am also in the process of adding a timer and best move and score values.

Videos

Links

Steam Greenlight

Released May 31, 2016May 31, 2016

Shape Quest

Help Mister Square save Shape Land by returning the super spinning power artifacts. Avoid touching all enemies.

Shape Quest Official Videos

Post Mortem

Ludum Dare 35 was my tenth time participating in the full Ludum Dare 48 hour game development competition. The theme this time was “shapeshift”. I knew fairly early that I wanted to make a game with controllable shape characters. My original idea was to have three shapes that you could switch between, and each shape would have a unique ability or power. I had envisioned having three playable shapes, which were the square, triangle, and circle. The gameplay was going to be similar to Trine, where the player would need to switch between the three to solve puzzles.

I wanted to take a break from Unity and create a game in some other engine this time. I had heard a lot about Godot, so I planned to use that engine for this competition. Godot is a free and open source game engine that is very similar to Unity. Before the weekend, I worked through some Godot tutorials, so I was able to move a simple sprite around on the screen. In Godot, instead of GameObjects, it has Nodes which have similar properties such as position, rotation, and scale. Godot can be used to make either 2D or 3D games. It has a scripting language that is very similar to Python, where tabs and spaces are significant. Unfortunately, I wasn’t ever able to fully understand the physics system. In Unity, physics is fairly simple. You attach a RigidBody component and one (or more) colliders to your GameObject, and then you are good to go. In Godot, there are three types of physics objects (KinematicBody, RigidBody, and StaticBody). Your object has to have a CollisionShape or CollisionPolygon as well, and everything has to be parented correctly under your main object. It was very confusing, especially with the bounding boxes, and it just never did work correctly for me.

After about four hours into development, I knew I wasn’t going to have the time to successfully make a game in Godot. Therefore, I fell to my backup plan which was to make a GameMaker game. I had heard a lot of bad things about how GameMaker handles things like collisions. Although, I have been impressed with some games that I’ve played recently, such as Crashlands, which was created in GameMaker.

Fortunately, most of my initial development was creating the vector graphics for the game characters, so switching to GameMaker didn’t sacrifice too much work. I had worked through some GameMaker tutorials before, but this was my first time creating a full original GameMaker game. The GameMaker development environment is very similar to Stencyl, which I used to create Dream World for Ludum Dare 30.

All of the graphics were created with Inkscape. I made a simple tree, which was composed of the union of three circles for the leaves, and a simple path for the trunk. I created other obstacles such as rocks (rounded gray rectangles) and water (curved blue bezier lines) I created a red square, green circle, and blue triangle characters, which all had two frames of walk animation. I had originally envisioned the heroes to use an additive color model, while the enemies used a subtractive color model (magenta, yellow, and cyan). I abandoned that idea, since a yellow circle looked much better like an emoji. I created a purplish trapezoid as the first enemy. I also had the idea of making the heroes parallelograms with sides of equal length, while the enemies would have sides of unequal length.

When I first started designing the movement of the playable character, I used the default GameMaker actions. The problem with this method, is that the character is stopped whenever one of the movement keys is released. So the player could be holding two movement keys (such as up and right arrows), but the player would completely stop whenever either of those keys are released. For instance, the character would expect to keep walking right if the up key was released. Also, with the default GameMaker movements, the chacter would move when the key was initial pressed, and would pause for a moment before it would continue moving. This is similar to typing into a text document, when a key is held down. First it adds the character, then pauses, then repeatedly adds the character multiple times.

To resolve this, I found a tutorial on making a platformer in GameMaker, so I just modified that method to work with a game in overhead view with no jumping. This method keeps track of a horizontal a vertical movement speed, and the speed values are modified based on which keys are held down. Now, the movement controls felt much more accurate and responsive.

Now that I had everything necessary to create a level, there needed to be a goal. I made a simple cyan diamond as a crystal. To differentiate it from the other world objects, I made it spin and flash between cyan and white. Adding custom scripts to GameMaker objects is fairly simple, and the GameMaker API is well documented.

The first enemy that I created was the purple trapezoid. It simply just moves vertically on the screen until it collides with an object, then it reverses direction. When the player collides with an enemy, the player is returned to the starting position. If I had more time, I could have added a health meter so the player wouldn’t have to restart after being hit just once. I gave the enemies angry faces with two frames of animation, which reminded me of the boxer profiles in Mike Tyson’s Punch-Out!!.

The second enemy that I created was the yellow circle, which was modified from my previous green circle hero. I just had to remove the arms and legs. The yellow circle just moves in a random direction for two seconds and then changes to a random direction and moves for another two seconds. This behavior is very easy to create in GameMaker, and I had remembered implementing the behavior in the “Catch the Clown” tutorial that comes bundled with GameMaker.

The third character I created was the green triangle. I wanted this to be a water dwelling enemy that shoots projectiles at the player. This behavior is similar to the Zora in the original Legend of Zelda. If the player stands in one position for too long, then they will be shot, so the player has to keep moving to stay out of the line of fire. The third level becomes more difficult with four green triangles shooting at the player at once.

The final enemy that I created was the orange pentagon. Originally, I had made the pentagon cyan, but I thought that would be too confusing with the cyan crystal goal, so I changed the color. The orange pentagon shoots in four directions at once and randomly changes location after every shot. These characters are similar to the Wizzrobes in the original Legend of Zelda, except they shoot in four directions. Their projectiles can be easily avoided, as long as the player doesn’t stand directly horizontal or vertical from one of the orange pentagons.

For the music, I used GarageBand again on my MacBook Pro. A few weeks ago, I had read an article on Gamasutra about music theory, and to watch the number of steps and skips, so hopefully my music sounds a little better for this game. I usually try different instruments until I find something that sounds good. I use the command + left mouse button to add new notes to the piano roll. I’ve found that it is much easier to modify the lengths and positions of the notes in Piano Roll editor than the Score editor. I used the C major key, so I just made sure I just stuck with all of the “white keys”. Overall, I think it took about an hour to create the music. Like I’ve done with my previous games, the title screen music is just the game music slowed down with some of the instruments modified or dropped.

I used BFXR for creating the sound effects when the player is hit or when the crystal is collected. I used Audacity for touchup work. I also recorded my voice again for the title screen and game complete screen. I used Audacity to add a bit of an echo sound. Unfortunately, my voice sounded a little faint against the background music, and I never found a way in GameMaker to make it louder.

There are many ways the game can be improved. First, I would like to give the player a method for attacking the enemies. I would also like to have a way to move from room to room, instead of collecting crystals. I would also like to have various items, money for purchasing new equipment, and many more enemies.

Finally, I played the game MANY times to ensure that all five levels were completable and also not too easy to finish. I made both Windows desktop (EXE) and HTML5 (web) builds, and uploaded to Itch.io and GameJolt. I think the Windows build is the better experience, but I know some people only prefer playing the web version. It just seems like there is more lag and dropped frames in the web version.

Overall, I was happy with the simple game that I was able to make in GameMaker. I really appreciate everyone who has played it already. It already has over 60 votes, which is by far the most votes of any of my Ludum Dare games have received.

Let’s Play Videos

Released April 17, 2016April 17, 2016