On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
The presentation should be 10-15 minutes long (shorter is better), followed by up to 5 minutes for questions
You should (with suggested minutes):
Explain the storyline and rules of your game (2 mins, 1 slide)
Demonstrate your game (2-4 mins)
Describe your game design at a high level (e.g. by showing a class diagram and explaining which class is responsible for which functionality) (3-4 mins, 1-2 slides)
Describe a technical challenge which you encountered during implementation and how you solved it (3-5 mins, 1-2 slides)
Game storyline and rules
Who do you get to be?
What do you get to do?
What is your goal in the game?
What are the obstacles/ rules?
e.g. My game’s called “Revenge of the couch potato”. You get to be a crime fighting vegetable setting out to save the Golden Carrot from certain peril. But one obstacle remains – King Tomato is making soup…
What makes a good speaker?
Think of an occasion where you have enjoyed listening to a speaker:
A memorable lesson at school?
Your granny telling you a story?
A friend telling you a joke?
The best man/bride/groom at a wedding?
What did the speaker do to engage you? How did the speaker draw you in?
Telling a story
You are telling a story.
The slides are NOT the story. They are to help you tell it.
The best presentations are mostly pictures/graphics/tables, not much text.
You can direct the audience’s attention by having elements appear/disappear, or text be highlighted.
Presentation will be marked on:
Content (what you say)
Delivery (how you say it)
Use of audio visual aids and demo
Marking - Content
Positive: Good explanation of software design, good understanding of the game design problem, clear explanation of game rules, well structured talk, highlighted important points, explained hard ideas well, questions handled well.
Negative: Unclear explanation of software design, poor understanding of the game design problem, unclear explanation of game rules, some technical errors, talk poorly structured.
Negative: Nervous, confused; delivery flat, hesitant, mumbled, voice too quiet, ran overtime, ran undertime, laboured easy material, skimmed difficult material, turned back on audience, obscured screen.
Marking – audio visual aids and demo I
Positive: Clear slides, right amount of material per slide, examples well used, diagrams/pictures/tables/graphs well used, game demo well explained
Negative: Omitted illustrative examples, would have benefited from diagrams/pictures/tables/graphs, slides too crowded, fonts too small, background too busy, typos on slides, game demo poorly explained.
Marking – audio visual aids and demo II
each slide or group of slides should help you tell a single aspect of your story
you should not normally need to re-show previous slides to tell your story (and never forwards)
Making explanations clear
Signposts – statements which indicate the content which will follow (e.g., overview)
Frames – statements which show the beginning and ending of sub topics
Foci – statements and gestures which highlight important points
Links – Statements which link different parts of the talk together, or to audience’s previous knowledge.
Summary – end with a summary of the main points of your presentation.
(From Brown, Bull and Pendelbury, 1997)
Examples of structuring
I’m going to start by describing my target user group.
You will have heard the myth that programmers are boring. But once you’ve seen my game, you can decide whether this is really true.
I’ve described the ideas behind my game, so now let’s see what it looks like.
This game rule is the most important: You must remember that you need the octopus’s help to fight the lecturer.
Remember I mentioned that the map would be randomised? This turned out to be hard. These are the challenges I faced…
I really learned something! I should start assignments early in the future so I have enough time to finish them.
Making explanations interesting
Show your own interest in the topic
Use examples and analogies which are suitable for the audience
If the material is unfamiliar, begin with examples
Use a mixture of modes: informal, personal and story-telling (but particularly storytelling)
Play on the intellectual curiosity of the audience through the use of puzzles, problems and questions.
(From Brown, Bull and Pendelbury, 1997)
Tips for presenting
Don’t write down what you’re going to say and then memorise it verbatim – this sounds very unnatural.
Don’t read out loud from pre-prepared notes if you can help it.
Practise on your own (computer better than paper)
Practise in front of kind friends/the mirror.
Spend extra time practising the beginning and end of your presentation so you project confidence.
Don’t turn your back on the audience, and make eye-contact
Check that your audience can hear you when you start
Check that they can read your slides, and the text on your demo (check these beforehand as well as at the presentation)
Audience rapport - presenter
Giving a presentation to a small group uses ordinary interpersonal communication skills. (Unlike lecturing!)
Look at your audience to check:
Do they look puzzled?
Do they look interested?
Are they following along with your argument?
Are they “on your side”?
You might find a friendly reassuring face!
Audience rapport - listeners
“ The best storytellers are the best listeners”
Be supportive to the people in your presentation group
Listen and show you’re listening (don’t “listen with your eyes closed”)
- Be courteous (don’t talk while the presenter is talking)
Be empathetic (it will be your turn soon!)
Start a question by commenting on a positive feature of the game or presentation before moving on to a suggestion.
Phrase criticisms as queries or suggestions – remember the presenter has spent longer thinking about this design than you have and you may be wrong.
Paraphrase the question
Ensures the rest of the audience heard the question
Gives you time to think
Be open to criticism, suggestions for improvements – try not to be hostile
If you considered the change but rejected it previously, explain your reasoning.