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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s