(lab) Slide and Catch Game Part IIStart Assignment
- Points 100
- Submitting a text entry box, a website url, or a file upload
Overview
This week’s project is an extension of the one from last week.
You should already have a project with the following features:
- A subclassed Scene for game play
- An avatar sprite controlled by the user
- User sprite will move in X or Y axis
- Use keyboard input to change sprite position
- At least one target sprite
- Target sprite is computer controlled
- It can move from top to bottom of screen
- Behavior should be somewhat randomized
- All sprites should consider boundary checking
- There should be a test for collision between player sprite and target sprites
- You should have a sound effect in place for handling collisions.
If you did not turn in a game with these features last week, we will provide you with a starting place template you can work with so you won’t fall too far behind
Gameplay labels
The game needs to have some kind of goals and obstacles. It’s important to explain this to the user so she knows what to do. We’ll do that in two ways. First, we’ll add feedback to the game screen. This will allow us to keep track of points, and will also allow us to place a countdown timer on the screen. Here’s the steps
- Create a label for showing the score. Get this label to appear on the game play screen
- Create an attribute for the game class called score. Initialize this value to zero.
- When a collision between the player and target happens, increment the score
- Make sure the label is always showing the current score
- When scorekeeping is working, add a second label for the timer
- Make sure this label is appearing where you want on the screen
- NOTE: because the timer label will need to update every frame, you may want this to be a subclass of the Label.
- Add a timer to manage the time
- Set the timer’s totalTime to the default length so you can easily make a countdown timer
- Display the timer’s getTimeLeft() value in the label
- When your specified time limit is over, end the game (scene.stop() could be useful here)
- Note that you’ll drive yourself crazy testing a game that lasts for 5 minutes each time
- There’s a reason my examples last for only ten seconds
- You can always change the time limit later
Adding a state system
The next part of the process is to create a state system. You’ll need to create a second scene to be the introduction scene. This will have the following features
- A multilabel containing instructions for game play
- A label containing the last score
- A button to play the game
- A second button to exit the game
Both buttons should stop the scene. At this point we aren’t worried about how to get the previous score.
Test your new scene in main. Instantiate and start the intro screen, then instantiate and start the game scene. At this point you will see the instructions, then the gameplay, and then the entire game will end.
Add a status attribute to the Intro class. Now modify the buttons so they still both exit the game, but report a different status (play or exit)
Modify your main function to have a standard keepGoing loop.
Inside the loop, play the intro scene, and then use the status to determine whether you play the game or exit the loop
Modify the Intro scene’s constructor to take a score value in the constructor.
Modify the main loop so the score from the game is passed to the Intro screen on each pass.
The Game Design Document
You started the game design document last week, but to get to all this new content, you’ll need to make your document more complete. At this point it should include:
- Some kind of diagram of game play
- Label each sprite on the screen indicating what class it will be
- For each sprite:
- What image are you hoping to have here? What’s its size?
- Is it a standard sprite or custom? Can it be BasicSprite or SuperSprite?
- How is the sprite born? Does it die? How?
- How does the sprite move? Is it under user or computer control?
- What specific motion mechanics do you expect?
- What happens when this sprite leaves the stage?
- What happens when this sprite collides with any other sprite on the screen?
- UI
- How will you explain the game before gameplay begins?
- What feedback will you give during game play?
- What UI components will you need?
- How will they be updated with necessary information?
- Where will they go on the screen?
- Game State
- What are the game states?
- How do you transfer between them?
- How do you communicate any needed information between states?
- How does the entire game eventually end?
- Sound effects
- What sound effects do you need?
- You can record them yourself if you can’t find something good
- When will the sound effect play?
- Where is the best place in code for the sound effect to be coded?
- Background image
- Will you have a background image?
- Where will it come from?
- Can you still see all the gameplay elements clearly?
- Intellectual property
- List where each image or sound effect came from
- If it is original, that’s all you need to say
- If it is open-source or creative commons, still link the source
- If it is copyrighted, get something else
- Placeholder values are fine.
Expectations
I have given you plenty of examples to start with. If you’re getting lost, please review the videos and examples, especially these:
- Your first game code examplesLinks to an external site.
- milestones 1-3 videoLinks to an external site.
- milestones 4-6 videoLinks to an external site.
- milestones 7-8 videoLinks to an external site.
You’ll get a better grade by having excellent documentation and adding to the core in some creative ways. Try to build your own game with your own dynamics. It’s fine if you don’t get the gameplay perfect on this go-around. Build a foundation you can build on with all the main mechanics in place. Have Fun!
