Week 4 – Failure and How I Blew Up

Making this post is very hard for me.

Last night while I was working furiously to wrap up this week’s project something went wrong.  Around 11pm I noticed that my Android Emulator in Eclipse wasn’t starting up and I couldn’t test my game.  I then started exporting my game onto my phone to test it there and it wouldn’t run.  At this point I figured I had messed up my code somewhere for the Android deployment.  But none of my previous week’s projects would run in Eclipse now.  None of them.  And I lost it.  I became rage incarnate.  This was not the correct thing to do.

My mind was racing.  I had one hour until my midnight deadline to solve this problem and I couldn’t think straight.  My stomach felt sick and I just wanted to scream every curse I had ever heard.  This, of course, didn’t help the situation and it became a downward spiral of anger and that anger clouding my ability to fix the problem.

I didn’t want to fail.  I didn’t want to lose.  I wanted to succeed and I felt helpless.  This week was feeling like my best one yet.  I had been so proud about how I was coming along this year.  I couldn’t accept failure.  I wouldn’t accept failure. I want to succeed.

Ultimately, 3am came around and I was still no closer to solving my issue.  None of my projects will launch in Android.  By this time I had given up putting the last little bit of functionality in my game and sat defeated with my the side of my face on my laptop.  I wasn’t just dead tired, I was dead.  Consumed with failure.  I didn’t know how to lift my head up from there and continue.  With my head turned into a paperweight on the keyboard I calmed down and proceeded to collect my thoughts.  I took a deep breath and said out loud the most painful thing I imagine I could have heard, “I failed”.  I accepted it.

I remembered that part of this year long project is to not only learn how to succeed but to not be afraid of failure.  Do not let failure bring you down.  It’s a tough lesson.  I would be lying if I said I thought that I learned it fully.  I’m still pretty upset, but I’m not discouraged.  I still plan to continue forward with Week 5 once I can get my IDE working again.  Hopefully that’s soon.  Once I am able to get everything running again I will be uploading what I had finished from this week in another post update as a record of what I made.


Week 4 – Planning & Scheduling

Lessons learned from last week:  Playtesting is worth your time.  Difficulty in a game should be progressive, I noticed that when I was playtesting Week 3 I had gotten better at it and may have made the game too hard at the beginning.  The importance of scheduling is not to be overestimated.

Week 4 is here.  I wanted to do something radically different this week to push myself.  I bounced around the idea of making a trivia game for a bit.  It didn’t interest me enough though, and for now that might be for another week.  What I have decided to make is a puzzle game.

The premise for this game is touching tiles of the correct color, as displayed at the top of the screen.  There will be a grid of tiles of random colors spawned on the screen that the player can touch.  At the top of the screen is a random color tile displayed.  The player is to tap all of the corresponding tiles on the grid that match the one displayed.  After all acceptable tiles are touched a new grid will appear and a new random color tile will be displayed at the top of the screen for the player.  This will continue until either a timer reaches zero or a set number of waves have been completed.  There will be two game modes, a “campaign” mode where there will be levels to choose from that progressively get more difficult and teach the player how to play the second game mode.  The second mode is an “endless” version of the main game.  This will be a culmination of all the lessons taught in the campaign version.  A main time will constantly be ticking down to zero.  Each wave completed will add time to the main time.  Once the main time reaches zero, the game is over and the amount of correct tiles will be shown as a score for the player.  This score will be reported to the Google leader boards, a new feature I’m incredibly interested in incorporating into my games.

The following screens will direct the flow of this project:

A Title Screen with the name of the game and a button to progress forward.

A MainMenu Screen with the choices of levels or endless, as well as the High Score for endless.

A GameScreen that operates appropriately to the game mode chosen (a level or endless).

I think that’s it.  Designing levels will be the toughest part I think so I want to dedicate a lot of time to it.  Going with my two hour block plan as last week, this project will be broken down into 11 blocks.

  1. Write the Title/MainMenu/GameScreen skeleton. // Fill in with appropriate buttons for transitions.
  2. Create a grid of 4×4 tiles to display on the GameScreen that fill with random colors (of Red, Blue, Green, Orange, Purple, Yellow).  At least 1 of the appropriate color will have to be available to be picked.
  3. Generate 1 working level where a Tile is shown at the top of the screen and the Grid spawns correctly and completes when the player selects all of the correct Tile.  Have Level select from MainMenu tie into this.
  4. Create levels based on teaching the player a single new idea/color. (Clear time will be the goal)
  5. (continue block 4…)
  6. Create endless mode (which should be easy after making levels), that incorporate all the ideas learned in the levels.  (Points will be the goal)
  7. Implement Google Leader board scores.
  8. Fix any loose ends and have game running and working as a rough draft.
  9. Playtest game and take notes
  10. Modify game based on notes and additional playtesting
  11. Release game.

I think I’ve really let myself fall into a trap with block 4 and 5.  That’s the least amount I wrote in my schedule but the part that I think will take the most time.  I figure one level to introduce each color, six levels.  In addition to that we’ll have the endless “level” so seven total.  At four hours for the six levels that’s 40 minutes to write up each level and with two hours allocated for the endless mode that I could potentially eat into, I would have a little over 50 minutes for each level.

Well, I think I’ve got a lot to get down and we’ll see how it turns out by Sunday night.  I plan to post and update sometime by Saturday this week to document some more about these projects.  Hopefully I have something cool to show off by then.

Here we go!

Week 3 – Complete

I’m happy about this one.  A lot happier than last week.  Having everything scheduled into blocks of time really helped me be more modular over the weekend when I got busy with non-Week 3 things.

That being said, I did have difficulty motivating myself on Saturday.  It resulted in me pushing a lot over to Sunday and spending a much longer time on it than I wanted.  I felt the repercussions after hour 6, I just felt exhausted and didn’t want to keep going.  But the deadline was approaching and I knew I had to finish.

Scheduling time for playtesting was HUGE.  I found a lot of quirks out that I wouldn’t have otherwise.  I completely removed the “slow down” button because it was unneeded.  I also changed how “lives” work.  It felt very abstract and non-intuitive to have the player just get hit a couple times and lose, I also had an issue where I felt like there was no reason to “explore the screen space” with the player because the top of the screen is more dangerous than the bottom.  I killed two birds with one stone and decided to make a line that slowly moves up the screen, and when the player touches THAT, they lose.  Now the player wants to get to the top of the screen.  The obstacles only stun you for a moment now instead of doing any significant damage.  In the beginning of the game it’s not that big of a deal, but the more obstacles you clear the faster the kill line moves up the screen. Also, I changed how the power-ups worked.  There was no need now for a score since the real goal was just to stay alive.  I changed the main objective to time elapsed from obstacles cleared to judge how well the player did.  Lives and Score were no longer power-up possibilities, but I wanted to do something to help ease the tension of the ever present “Line of Death” moving up the screen.  Instead of an Invincibility Power-up I had planned, I instead made a simple little visual counter for every obstacle that you clear in a row.  If you get 8 in a row, the kill line resets position, but keeps its speed.  After playtesting this for a while I was really happy with the rise and fall tension that would occur, and how those ups and downs came at faster and faster intervals.

So, playtesting paid off a lot for me this week.  I saw something that wasn’t going to be fun, and was able to cut it, reflect on what the feel of the game was, and add something more fitting in it’s place.  Scheduling my time into blocks also helped me accomplish these changes.  Modular planning let me cut out one block or modify it without throwing the rest of my project into chaos.

I finally spent some time on making my other screens besides the main game screen look a bit nicer.  I did it in a very poor way, just loading a single texture on a black filled background.  Mostly because I spent too much time on Android debugging.  This week I was able to get the HTML to compile but for some reason clicking doesn’t do anything.  I thought it was fixed because it ran but when I went to click on the first button to Start the game nothing happened.  It’s going to be linked even though it doesn’t currently work.  I’m hoping the fix isn’t something I have to do in the programming, because I’m not going to touch it again for a while.

Week 3’s project can be found on:
Google Play Store
in a Browser
download from Dropbox


Week 3 – Planning & Scheduling

I feel rested.

Taking what I learned about scheduling from last week, I have a new approach I’m going to try this week.  I’m going to carve out a block of two hours on Wednesday and Thursday, and three blocks of two hours for Friday, Saturday, and Sunday.  Each block is enough time to implement and finish one task.  Once that block of time is up, that task is completed and no more time will be spent on it.  Saturday’s final block will be spent fixing errors and bugs and refining my game and no new features to be implemented.  Sunday’s blocks will be spent on playtesting, polishing, and deployment respectively.

This will allow for seven tasks to be implemented before the final block Saturday is spent fixing errors.

Let’s see how this framework will look with this week’s game idea.

Week 3 is going to be an auto-scroller/runner type game.  Deployment will be for Desktop, Android, and Browser.  From the Title Screen, containing the name of the game and a how-to-play, a button can be pressed to move to the Game Screen. There will be a top down perspective as the player’s sprite runs in the middle of the screen toward the top of the screen (the sprite will stay in the same location relative to the screen, the rest of the level will move past him), slowing down and speeding up from player input, in order to dodge obstacles.  Player input will take the form of two buttons, a slow button and a sprint button, but the player will always be moving forward.  The main obstacle is two “logs” that start on the left and right sides of the screen and “slam” together in the center and then retract.  This log trap will move at a constant rate but there will be one set that closes fast and opens slow, one that closes slow and opens fast, and one that opens and closes at a normal speed.  These obstacles will be introduced to the player one at a time for the player to learn how each of the four types behave.  This will require level design that can successfully introduce and teach a player how to respond and reward them with their correct response.  Clearing an obstacle will net you points.  Clearing more than one log will award a chain bonus.  Hitting an obstacle will deduct a life and reset the chain bonus.  To contrast with avoiding obstacles, sometimes powerups will float across the level that you will want to run into.  These powerups will be Invincibility, Bonus Points, or a 1up.  Invincibility will give you a brief flashing animation and a short duration of automatically clearing obstacles.  A Score, Time, and Lives count will be placed at the top of the screen.  Once all Lives are lost a Game Over is displayed and the game returns to the Title Screen.

So, let’s apply this game to a schedule:

— Total Blocks Planned —

7 Blocks to get features working

1 Block to clean up the game into a fully working state

1 Block to playtest

1 Block to polish

1 Block to deploy

11 Blocks Total.


1. Have player sprite, with running animation, controlled by slower and faster buttons.

2. Have an infinitely scrolling empty level with music.

3. Have an obstacle that opens and closes with a with a “boom” sfx upon contact

4. Create collision between logs and player, and deduct a life (giving invincibility frames), playing a hurt sfx or adding score/chain and playing a success sfx appropriately.

5. Create a HUD at the top of the screen that gives player feedback regarding Score, Time, and Lives.  Also popup score numbers next to the player every time they pass an obstacle.

6. Create a powerup that will randomly appear and float horizontally across the screen for the player to run into (this power up will bounce of the sides of the screen and not move with the level).  After a duration of time the powerup will disappear.

7. Design beginning of the level’s obstacle layout to teach the way logs behave.

8.  Clean-up the project into a working skeleton in addition tofilling out the title screen and adding a game over to the game screen that will loop back to the title screen.

9.  Playtest to check for quirks and bugs

10.  Polish up the game based on Playtesting block finds.

11.  Deploy game and check for intended behavior on various platforms.

Well…Today is spent preparing everything.  Time to make/gather assets and write up all the skeleton code.  Week 3 has here we go!


Week 2 – Complete

Week 2 is finished.

This week I had laid out huge aspiration for a space shooter type game.  I ran into some issue like, figuring about how the enemy ships would behave, messing up the HTML deployment, and not leaving enough time to playtest.

So, this week, there is only a download link and an Android Play Store link.

GOOD : I managed to complete most of my goals i set out for myself.  In comparison to last week I think the game itself looks much better.  There’s color, there’s music playing, it just feels better.  Also, I wasn’t afraid to cut ideas that weren’t going to make it in before the deadline.

BADDuring this week I realized I would’ve been better served scheduling my time out into blocks (in this block of time I work on just this and when that time is up I stop).  Similar to how I’m doing one game a week, I could utilize that same process for one block of time a feature.  Because I would shift my focus around the project when I worked I feel I lost time and ended up with a bunch of things that were somewhat done instead of three or four things that were done.  Also, when planning this week I never left time for playtesting my game before deployment.  When the deadline was getting close I was exhausted and realized that I was going to put something out that didn’t deploy correctly to Android and just wouldn’t compile to HTML.  That cause the game to suffer.  Buttons are too small on Android and make it awkward to play.  Despite the bugs that I failed to have to resolve, I actually thought I would’ve had an acceptable game for this week on Android.  But with the button size issue, and having left myself no time to fix it, I did what I had to do: make the deadline and I released an inferior product.

And it hurts.

LESSONS LEARNED : Scheduling goes hand-in-hand with planning.  Plan for things to go wrong.  Plan to playtest.  UI is a lot more important than I was giving it credit for, if a player can’t reasonably interact with the game then they aren’t going to play it.  Parallax backgrounds are fun and easy.

Week 2’s project can be found on
Google Play Store
download from Dropbox


Week 2 – Planning

Taking the lesson learned from last week, I’m going to have a little more forethought about this week’s project.  That being the case, I figure I’ll write about it here and then after the deadline on Sunday night I’ll see just how much I was able to accomplish.

A major problem I had with Week 1 was that the instructions on how to play just weren’t present.  Maybe after a couple tries you could figure it out, but it should be intuitive, and if not, just explained simply.   This week’s project will have a simple splash screen explaining the controls.

The plan for Week 2 is to be a space shooter.  Upping the ante quite a bit from last week.  In the vein of the arcade classic Galaga.  You will control a ship with left and right movement and have the ability to fire bullets at enemy ships.  Enemy ships will come in two types: One that fires back and one that doesn’t.  One hit against the player from an enemy ship will destroy it and cost the player 1 life (of which they will start with 3).  Enemy ships will require multiple hits to destroy and then turn to particles.  Destroying ships rewards the player with points and potential powerups (extra points, extra lives, and momentarily shooting faster).  Score will be displayed at the top of the screen along with a player’s High Score.  To simulate the feeling of flying through space, a scrolling starfield effect will be present in the background.  Ambient music will be played during the game with SFXs for when the player fires, the enemy fires, a ship being destroyed, or collecting powerups. The full game will take place over 2 screens: a title screen with the name of the game and simple instructions as well as a button that must be clicked/tapped for the player to proceed to the next screen. That screen will be the main Game screen where the player will proceed to control his ship with the left and right button and fire with the fire button in order to destroy ships to collect points while avoiding return fire. Once all player lives are lost the game will popup a game over and score and allow the player to press a button to restart the game.

That is a lot.

And no more will get added from this point forward. It is now locked in, and I expect features to get cut. I kinda went overboard with it on purpose, knowing full well I’d be making cuts.

Let’s see how this vision turns out in the next 5 days.


Week 1 – Complete


Plan. Plan. Plan. Plan. Plan.

If I have learned anything this week is that you need to be planned out before you start.  It almost seems unfair, because the things I didn’t know I needed to be planned for were the things that hindered me, but that’s why I’m doing this, so that I can conquer ignorance.

Because of my hours I work I new I really wasn’t going to have any lengthy amount of free time until Saturday and Sunday.  Knowing this I did a lot of setup during the weekdays so that once the weekend came I could really get to work.  Since this is the first week, I planned to create Pong.  I have never “finished” a game, let alone published one, so I wanted my project to be super easy so I could figure out what I needed to do to deploy, publish and release a game for the first time.  I was very frustrated finding a lot of unhelpful posts on various websites on how to “fix” deployments for html and android and I felt like I wasn’t going to be able to ever figure it out.  I ran into small issues like not having the correct plugin for my IDE and just straight up not understanding a lot of terms, feeling like an idiot, and getting lost.

But, now I do know…at least a little more than I did before.

When I set out to do this my focus was set to be on finishing a game.  I found myself wanting to add a feature here or there to spice up something as bland as pong.  For example: letting a second player option exist, having particle effects on the ball, or making the AI better.  All these things were doable, with just a little more time.  In fact, I realize that’s always been my approach in the past.  That with enough time I could finish something.  By taking awake “infinite time” as a resource and making a set deadline, I was really focused on getting to an endpoint.

The one feature I did modify from regular pong is that every time the ball bounces off a paddle it increases speed slightly.  It didn’t take much time to implement and it was just on a whim, but I found myself play-testing the amount of speed increase to what felt right and realized I was just wasting time.  A feature that took all of two extra keypresses to enter ( “speed *= -1” became “speed *=-1.1”) was costing me a lot more time than “it’s just two keypresses”.  The code didn’t take the effort, it was me trying to understand the effect it was having.  Additionally, the wanting to add a second player option was taking up too much time.  I thought about how you let the player choose that option, likely with buttons.  Where should these buttons go?  How should they look?  What should they say? Should they animate when pressed?  Do they need a sound effect?  And then it takes time to test out each of those answers…and sometimes there’s more than one answer…which is the best? Could I have done these things? Sure, given enough time.

Lessons learned: Plan ahead and Adding features cost more time than you think.

That being said, I did finish.  Week 1’s project can be found on:
Google Play Store
in a Browser
download from Dropbox

Week 2 coming up!