In design thinking, one way of doing things called the "d.school" model from Stanford University. It has five steps:
Empathize: This is like putting yourself in someone else's shoes. You watch, listen, and talk to people to understand who you're designing for and what problem you're trying to solve.
Define: Once you understand the problem and the people involved, you write down a clear statement that describes the challenge. This statement guides your actions.
Ideate: In this step, you and your team come up with as many ideas as possible. You don't judge them right away; you let your creativity flow to find new and creative solutions.
Prototype: Now, you start building a version of your solution. It's okay if it's not perfect at first. You can make changes and try different things. This step doesn't need a lot of time or resources.
Test: After you've made a prototype, you show it to the people who will use it. This helps you understand their needs better and make your solution even better. You keep going through these steps and making improvements until you have a good solution.
Remember, you can go back and forth between these steps, and they don't always have to happen in order. It's all about being flexible and finding the best solution by trying things out and learning along the way.
"Guardianship, stewardship for living things and resources."
This is a key concept in design and once you understand it we will develop ways that we can show it in our designs. Watch the video and think about how we might show Kaitiakitanga in deciding what to design and how we design it.
"The process of showing respect and care; reciprocity between people, living things, and places."
Manaakitanga underpins a lot of what designers do when they talk to people, listen to people and design for their needs.
Watch the video to get a better understanding of what manaakitanga is and have a thing about what you might do as a designer to ensure you show manaakitanga in what you do as a designer.
Through this Standard, ākonga are required to discuss manaakitanga or kaitiakitanga as they create their design, drawing on several pieces of significant learning. In other words, ākonga may:
evaluate the fitness for purpose of digital technologies outcomes by considering manaakitanga or kaitiakitanga, and the outcomes’ social and physical environments
understand how digital technologies impact on end users by considering the following mātāpono Māori: kotahitanga, whanaungatanga, manaakitanga, wairuatanga, kaitiakitanga, and tikanga
understand that digital technologies and the concepts that underpin them are influenced by the people that create them and the contexts in which they are developed
recognise that through kotahitanga and creative and critical thinking they can develop new and innovative solutions to existing problems.
Digital outcomes do not exist in isolation from the context in which they are situated, and the consideration of manaakitanga (the process of showing respect and care to others) or kaitiakitanga (guardianship, stewardship for living things and resources) should be central to a design and development process.
In discussing manaakitanga, ākonga will show respect and care for others, specifically the users of an outcome or those that may be impacted by its use. As they go through the design process, ākonga may ask themselves:
How will my design uphold the mana of a user?
How can I design the outcome to be as easy to use as possible?
How will the thing I’m designing improve peoples’ lives?
How will my design remove barriers to access for a range of users?
How can I respectfully involve the potential users in decisions about my design?
How might other people be impacted by the outcome I’m designing?
In discussing kaitiakitanga, ākonga will show respect and stewardship for living things and resources. As they go through the design process, ākonga may ask themselves:
What are the resources my outcome would require and what is the environmental impact of those?
Are there choices that I can make with my design that would be more or less harmful to the environment and living things?
How can the outcome I design support or promote conservation or protection for the environment and living things?
How can the outcome I design support kaitiaki in their role?
How can the outcome I design reduce the excess consumption of resources?
Ākonga will demonstrate the application of feedback in the development of their design and explain how their design decisions improved the fitness of purpose of the design.
Justifications of how decisions made during the design process contribute to the design’s fitness for purpose may consider:
requirements
potential users
usability principles
design principles.
Article on the Spinoff by Felix Walton
In this document you will compile a portfolio and Game Design Document to guide you through the design process.
Make a copy of this document.
This will be the main document that you will complete for this unit of work.
Use the following resources to help you fill it out more effectively.
There are also some example GDDs that you could look at for some very famous games at the bottom of this page.
With every technology outcome you need to describe a need or opportunity and potential user.
Read some examples of things that video games have been used for.
Foldit attempts to apply the human brain’s instinctive abilities to the problem of protein structure prediction.
But for most video games are for entertainment! This is the need you are likely need you are going to fulfill with your game.
Using the above resources and what you wrote in you Kaitiakitanga and Manaakitanga worksheet Complete Step 1 of your GDD
Watch the video by BlackThronProd and start brainstorming some ideas on your document. There are some helpful questions to think about and get your brain going. You are then going to write 3 synopsis for games you could make.
Complete Step 2 in your Game Design Document. Get out some paper and pencils and when you are done scan this into your document.
As your first game it is VERY important to set a good scope for your games. This video goes over some general ideas for what types of games you can make.
Scope - In video game design, refers to the overall size, complexity, and scale of a video game project.
You have come up with some great ideas but what is feasable? Watch the video and look at the lists below so you can start thinking of what you could actually make.
Platformers (Easiest option)
Top Down games
Endless runners
Point and Click games
One Mechanic games (Flappy Bird, Frogger, or Super Hexagon for instance)
Make a multiplayer game.
Not have clear ideas on how the enemy AI will work.
Having a complicated story or characters.
Having more than a handful of different things you need to animate/draw/design.
Insufficient planning.
Use the above information to come up with three synopsis in your GDD.
Complete Step 3 in your document now.
Now that you have some ideas it is time to chose one of your options. Below are some videos and further information to help make the decision about which game you should make. Show some manaakitanga, find people to talk to who might give you good feedback. And listen to them to help make your ideas better.
Complete Step 4.1, 4.2 and 4.3 in your Game Design Document now
In the next section, you'll create a prortype Game Design Document. We'll call it a propotype, because it is a "work in progress" document and will change as we learn more! Complete Section 5 of your main document now and use the following information to help you fill it out correctly.
By the end of this you'll have a refined GDD that has been improved by feedback.
Work through each section at your own pace using the resources to help you if you need.
This is the most straightforward part of the document and should be pretty self-explanatory.
A game flow diagram is like a map that shows the journey a player takes in a video game. It's made up of boxes and arrows. The game flow diagram helps game designers plan how the game will work and helps players understand what to do next. It's like a roadmap that guides you through the adventure of the game! Watch the video for a basic rundown of flow diagrams. After that make your own using Lucid Chart. You can use the example as a guide.
Introduction to flow charts
Example of a game flow diagram
Possibly using the keyboard and mouse diagrams on the right layout what the keys in your game will be. It is good practice to use keys that are often used in other games for example movement being WASD and/or arrow keys.
This video helps you to understand how to sketch up UI for your game.
Your color choices are important. This video helps explain what the colors are and hoiw you can use color to help covey a feeling.
This will help you make good choices for your designs for your characters and scenes. Get sketching!
If you are not a confident artist you can use an art pack either entirely or as a starting point. These are some excellent sources of creative commons or public domain assets. You can check some of these out the bottom of this page.
Simplest to Most Complex
Stationary
Things like spikes and lava does not need an AI
Linefollow
Simply move backwards and forwards from point to point.
Reactive
For example where a enemy has a detection radius and then chases or runs away.
Proactive
Using a pathfinding algorithm to avoid obstacles and move to changing destinations
Sounds and music are one of the best ways to take your game up a notch in terms of aesthetics and game feel. You don't need to make game sounds or music there are plenty with various creative commons licences online. But it can be fun making some sound effects with your phone microphone and a little bit of tinkering in Audacity!
What sounds do you want in your game? List them in section 5.7 of the document now.
The topic is quite hard to grasp and you are going to have to be able to write a clear set of requirements (what someting must do) and specifications (how exactly it's going to do it) for your project idea.
Watch the video to help get a good understanding of the topic and then complete the worksheet below. Make sure you make a copy of the doc and then have a go filling it out. All instructions are inside the document.
Requirements are like the rules a game has to follow to make players happy and meet the project's goals. They tell us what the game needs to do and set limits on what we need to accomplish. There are different types of requirements:
Functional Requirements: These rules say what the game has to do. For example, "Players must control a character like in a platformer game" or "Players need a health system where they lose health when attacked and can get it back by picking things up."
Non-Functional Requirements: These are about how well the game should work, like how fast it should run, how reliable it is, and how safe it is. For instance, "The game needs to run at least 30 frames per second on all devices."
Quality of Life Requirements: These rules focus on how players feel when they play the game. This includes things like easy controls, smooth animations, clear tutorials, and menus that respond quickly.
Compatibility Requirements: These rules make sure the game works right on certain devices and software setups.
Specifications are super-detailed descriptions of a video game. They tell us exactly how the game should work and what it will look like:
Technical Details: This tells us , like what kind of game engine it uses, where you can play the game (on a computer, game console, or phone), how good the graphics and sounds will be, and if you can play with friends online.
Gameplay Mechanics: These are the rules for how the game works. How you move and do things, what your goals are, how you go from one level to another, and if there are special things like playing with others or computer-controlled characters.
User Interface (UI) and User Experience (UX): This part is about how the game looks and how you interact with it. It includes menus, buttons, maps, and anything you see or click on while playing.
Art and Design: This is all about how the game looks, including the characters, the world they're in, the animations, and special effects that make the game look cool.
Sound and Music: Here, we talk about the sounds in the game, like footsteps or explosions, and the music that plays in the background. It's what makes the game sound great!
What do you HAVE to make this game, what people, what skills do they have, how much time, what software, hardware etc. This helps you to judge if a game is in scope (ie do-able with the given resources)
Think hard about this and list them all in section 5.9 of your game design document.
The number one rule for feedback with design work is give options! The person that you are getting ideas from can't imagine your main character in different colours, instead present them in the different colours.
This is your last chance to show manaakitanga.
Go and show your friends, whanau, and anyone else your GDD and listen to what suggestions they have to make it better.
Once you've got lots of feedback, go and make improvement to your GDD.
At this point you may want to get some feedback, especially if you have options but not quite sure which path to follow.
Giving and receiving design feedback is tough. Feedback should be helpful, could improve the work, move things forward and bring about confidence. Quite often feedback is unconstructive and can be ill-aimed, irrelevant, antagonistic.
Feedback needs to be constructive… and honest
But what does it mean to be constructive?
Adjective
1. serving a useful purpose; tending to build up
Next, you'll need to try to justify, with evidence, why this design is going to be awesome.
Does it fit the theme?
How will it meet the needs of the target audience?
How will you respect the principles of manaakitanga? Kaitiakitanga?
Don’t forget to include research to back up your claims. Use the internet and add a bibliography of websites or articles that you used. The better you do this section, the better prepared you will be for the exam.
Fill out section 7 of your GDD now.
note: Justify - To support an argument or conclusion with evidence
A Game Design Document (GDD) is super-detailed plan document that tells you define everything you need to know when making a particular video game. It has all the important details about how the game should look and work. It helps the people working on the game understand the game's idea, rules, and how it's supposed to work.
Game designers are the ones who usually make this plan, and it's like the base or starting point for everyone involved in making the game. This is then used by everyone; programmers, artists, writers, level designers, musicians, and project managers to work collaborativly. If everyone knows what the game should be, they can all work together to make sure the game ends up like it's supposed to.
Unity Zombie Toys GDD Example
Creative Commons and Public Domain Assets you could use in your game
https://incompetech.com/
Level designs
User Interface (HUD, life, bullets etc.)
Enemy models
Title screen and credits
Game flow diagram
Layout of website
Pictures
Navigation Bar
Text location
Aesthetics (font and colour)
Highly dependent on design but elements could include:
Hats
Pets
Stance
Weapon designs
Wheel rims
Storyboard
Title cards and credits font and colour
Filters and effects
Music
Storyboard/script
Cover Art
Music
Components
Circuit diagram
Casing
Board and card art
Component size, shape, material
Layout
Rules booklet
Paper Prototyping
Game Design Document
Sound Design Document
Poster Design Document
Web Design Document