Ludum Dare 37 – Update 4

There’s only a few hours left, so I am going to stop adding features and start tweaking and bug fixing on my game, Bat Cave.

Shoot and avoid the bats.  Shoot the drips coming from the stalactites so they do not build up stalagmites on the ground. You can jump over smaller stalagmites, and shoot the bomb power-up to remove them. Shoot the bullet power-up for 10 seconds of extra fire power.

Ludum Dare 37 – Update 3

Just after midnight Saturday here, and I am tired. I have a playable cave shooter game. Next up is to add some background graphics, tweak the sounds, graphics (I hope), and game play, and add a few more power ups. I hope to get all of this done in time.

It’s a simple, one room shooter, but for some reason this one gave me a lot of problems. Collisions were giving me a headache. Some features were removed since they kind of sucked once I started working on it. Other features were removed due to time.

All in all, it’s a bit primitive (due to my lack of any art skills), but enjoyable.

schizoid2k-ld37-update-3

Ludum Dare 37 – Update 2

Eighteen hours in (minus some sleep), and here is my cave shooter,  tentatively titled “Bat Cave”.

Shoot the drips to prevent stalagmites from forming. Avoid the bats.

Things I still have to do:

  • My abysmal graphics show the game play. I hope to have time to tweak these later.
  • I still have to add power-ups that drop down the mine shaft.
  • Scoring, sounds, music, and other cool effects.

I decided to go with a gun turret as the player. I tried to create an animated person running around, but it didn’t work out. I stink at creating graphics, and was spending a lot of time on it.

Ludum Dare 37 – Update 1

I decided to write a game where the player is in a cave. This is the “one room”. This idea would of also worked for other themes not chosen (underground, etc).

The first 2 hours were spent on design and moving some Unity objects around to get the coding working. I do suck at art, but attached is a rock-like room that you can consider a cave with stalactites. If I have some time later in the compo, I will revisit the art, but for now, this is the best I can do under the time constraints I set for myself. The stalactites are randomly placed when the game starts.

Next up is to create the player, mine shaft, and some power-ups. The idea of the game is to destroy the drips from the stalactites. If the drip hits the ground, it starts creating a stalagmite and makes it difficult for the player to move around.  Power-ups come down the mine shaft and help the player destroy the stalagmites, or gives the player a special ability to cope with what’s going on.  I think I will add some bats for added frustration!

ld37-screenshot-1

Tip: Using GBC Language Cabinet With Larger Applications

Background

GBC Language Cabinet is my free CoronaSDK plug-in that helps simplify the addition of multi-language support in your games and applications. Using GBC Language Cabinet is very easy… define the languages you want to use, add the translation text, and then call a function to retrieve the appropriate text in a specific language.

For smaller games, it is very convenient to create a separate Lua module to create and add all the required text that you need within the game, but what about larger applications that have many scenes and/or a large amount of text? What about scenes that are only displayed one time? In these cases, one large Lua file will work, but it is possible to use multiple Lua files to help you manage the large amount of text needed for games such as this.

Modular Approach to Translation Text Managment

For example, translation files can be created per scene, or included in each scene’s create() method…

-- remove all text entries currently stored in GBC Language Cabinet
GBCLanguageCabinet.clearText()

-- load scene specific text
GBCLanguageCabinet.addLanguage("English", "en")
GBCLanguageCabinet.addLanguage("Deutsch", "de")
GBCLanguageCabinet.addLanguage("Español", "es")

GBCLanguageCabinet.addText("RedBall", {
    {"en", "That is a ##color## ##object##"},
    {"de", "Das ist eine ##color## ##object##"},
    {"es", "Esa es una ##object## ##color##"},
})

Notice that for each scene, you remove all previous text, add the language, and then add the text.  This ensures that only the scene specific text is available.  This keeps the memory footprint lower, and makes management of text easier.

In Closing

GBC Language Cabinet is flexible, so the best approach is really up to you. It depends on your game and how you would like to manage it. Using a modular approach allows you to manage translation text in cases where a large number of scenes or a large amount of text makes a single file solution difficult.

I am always interested in knowing who uses GBC Language Cabinet… show me your games! Also, if you have any suggestions for improvements, please let me know.

Post Mortem – Pumpkin Patch Match

I originally wrote this article in October of 2015, but never published it.  Since I just released an update to Pumpkin Patch Match, and since we are coming up on Halloween, I decided to make a few edits and finally release this Post Mortem.

Background

Pumpkin Patch Match bannerI wanted to create a Halloween themed game along the lines of my past two holiday releases, Tappy Holidays, and Tappy Valentines Day. Tappy Halloween, as it was going to be called, was going to be a simple game with the same game mechanics as the first two games in the series, but I just couldn’t figure out a game that would be interesting.

After a couple of weeks of trashing ideas, it came to me… make a game where you have to match a pattern of jack-o-lanterns. Shortly after, I decided to change the name to Pumpkin Patch Match since it seemed better suited for the game.

Putting It Together

I have been learning Unity throughout the first part of 2015, and I thought that this would be a good “first game”. I got pretty far, and was pretty impressed with it, but what I thought were a couple of limitations prevented me from continuing, so I went back to CoronaSDK for this app.

I put together a CoronaSDK based application in no time and I am very happy with the results. I feel it is one of my better developed apps.

Stuff I Encountered
  • CoronaSDK is great for 2D games. I built Pumpkin Patch Match rather quickly, but I’ve been trying to find a reason to move completely to Unity. I guess both have their strengths and weaknesses. I am close though, since there are a few things that are a bit limiting with Corona.
    • 2016: Looking back, I think I should of continued to use Unity… it would of been a great learning experience.
  • I decided to try Vungle for monetization… let’s see how this pans out. I hate ad based games, and I’ve been trying unsuccessfully to get out of that, but I don’t seem to have a choice. My games with In-App Purchases, or games I originally released as a pay-to-play (no ads) were unsuccessful.
    • 2016: Still not sure Vungle is the way to go.  It fits well with the game (allowing the player to continue at the same level if he/she watches a video), but I do not see the profits I expected.
  • I am also going to release on the Windows Phone platform. I have no experience there, and have no idea how this will turn out. CoronaSDK recently released a Windows Phone build.
    • 2016: I did release a Windows Phone version, but since Vungle on CoronaSDK on Windows Phone is not supported, I had to go with a $0.99 app, and as I expected, not a single purchase was made.

SMS: The Next Mission – September Update

Lots of progress this past month, despite trying to get some coding in due to other obligations. I successfully added an “80s Home Computer” mode to SMS. Below is how it currently looks… pixel graphics, classic fuel bar, and 8-bit text in all its glory.  Click the image to see a larger screen shot.

80s Home Computer
80’s Home Computer Mode

I spent a lot of the first half of August researching how to handle the graphics for this mode.  I though of recreating all the graphics in pixel art, but it seemed like a lot of work to animate the ship to give it a true 8-bit rotation look.  I tried a shader, but it was a bit limited due to the layers I was using in the game. I finally settled on using a render texture, and it works great. I think it captures the look and feel of the 1980s. The score and fuel gauge were then created on a HUD UI layer.

Scope Creep

It’s been about 7 months since I started this project (albeit “off and on”), and I am still adding features. I still want to add an optional “60’s Mainframe Mode”, and I haven’t started on the “Current Year Shmup” mode (although I have some ideas). Once I get these modes where they are playable, I would like to release some video and a playable demo.

This month I plan on tweaking the graphics and code for the 3 modes, defining what I want in the Shmup mode, and putting together a title and options screen.

SMS: The Next Mission – August Update

It’s been a few months since my last status update for SMS: The Next Mission. Over the past two months, I have decided to remove, then re-add, the shmup version of the game.  I am also again on the fence on whether I should include multiplayer support like I had originally planned (and then decided against).

Originally, I wanted to recreate the mobile version of Space Mission: Survival on the PC and Mac.  A desktop version has been running in development for several months now. The PC opens up a lot more options, so I wanted to add a lot of bells and whistles including multiplayer, and expand on the “Classic 90s” retro look.  A bit later, I decided to drop multiplayer and focus on single player.  I added a “Retro 70s” look as well.

A couple of months later I had a playable game that had two styles, Classic 90s and Retro 70s.  Same game, two styles that the player can play from beginning to end. At this point I decided that maybe it would be cooler if the player was some sort of time traveler and can warp to different video game eras. I like it!

So, right now, I have a Retro 70s, Home Computer 80s, and Classic 90s version of the game. The 2000s version will be the shmup level and I will start development on that soon. I am actually thinking of adding a “Text Based 60s” mode to see if I can pull that off.

I am trying to keep each level accurate to the decade. This includes graphics and text styles, sound, and game play.

I am not sure if changing my mind so many times is a good or bad omen, but I believe the current idea of traveling through decades and playing the game with features available at that time will be fun and challenging. The only other decision I have to make (other than a name change, perhaps) is whether I want to add (local) multiplayer support, which would be ideal for consoles.