Showing posts with label Week 6. Show all posts
Showing posts with label Week 6. Show all posts

Sunday, November 8, 2020

Game Design Document

 The GDD was fun to work on. It helped to reveal areas in the game design that where lacking or  missing  which you wouldn't think of initially because the document is very in-depth. There's a lot to think about. I know I'm done with it yet as it is a living document but I feel I might be going in the right direction with it. 

Initially, I wanted to stick with Word for the GDD as it was something I was familiar with however, I'm glad I decided to take a plunge into something new. Dundoc turned out to be very simple to use and VERY easy to maintain and LESS time consuming compared to Word. 

Dundoc has some templates ready for you to get started with. However, I decided to make my own following example from Mark Baldwin's GDD template layout. Here's a link to my GDD: https://www.dundoc.com/project/6917/neta3be22v

One of the areas I need figure out about the game is to look for assets in terms of surroundings and some other animals. Here's some images from a game by David Wehle - The First Tree. I don't too much about the game, but I found the images inspiring and could help to think about the look and feel of the game. 




Friday, November 6, 2020

Unity Tutorial 05

 

This week’s tutorial has been interesting. We learned some features that made our game more game-like. I realized how more comfortable I was when working through the tutorials, especially with the scripts, I was able to recall some code we used in previous tutorials.

The lessons focused on creating a fast-paced runner game where the player needs to press the spacebar to jump in order to avoid obstacles which fly towards the player.

I got a bit insight on a different way to make game objects do different things. So far,  only the Translate () method was used to bring objects into our scene. However, to make the game seem a little more realistic I got a little more insight about Unity’s own physics engine which calculates the objects mass, external forces acting on that object and gravity which simulates real-life physics in the game.

In this tutorial, I had to use the AddForce method instead, which uses Unity’s physics engine to make the character’ jump force realistic.

Screenshot of my Unity tutorial.

The Sprite Render component is a new feature I was introduced which essentially rendrs images into the game and can be used to create the 2D background just the like the forest background used for this game. We were able to make it appear like the player was moving by applying a written move script to the background (kind of like looking out the window of fast driving car).

Another useful skill was to call other methods to target different game components. Before, we only used gameObject and Transform.

To control the character’s movement, gravity and other characteristics we used new method to be able to access other components which aren’t found on every game object such as the Rigidbody. To do that we used GetComponent method.

Finally, the more part was learning to do our first animations. Animation Controller with an unusual interface that looks similar to  a mind-map diagram. When viewing the game on play-mode, the diagrams will indicate what animation state the character is in. The parameters section allows use to control the length and speed of an animation. We also managed animation transitions in our scripts using if-statements to control when the character enters different animations states depending of what the player does e.g if player accidently hits the obstacle the character transitions from a running state to an animation where he is knocked unconscious.

This was a fun unit overall. Hopefully I’ll be able to remembers most of what I learned when it comes to making my own game.

Monday, November 2, 2020

Games GDD

 

What is the GDD for?


A Game Design Document (GDD) is a blueprint for the design and development of a game.

The GDD is a way of being creative and documenting the approach to the development of the game. Gonzale (1999) states that “ the important thing is to have something that describes your game project (or any other project for that matter) before jumping into production.( Gamasutra ) It should help to plan out your game. Though it is recommended that the GDD should be short it needs to be detailed enough so as game developers and artists can coordinate the development of the game independently whilst still keeping to the design. The GDD is a blueprint for how the game is going to be designed and built, similar to a mind map. In conclusion, the game design document is vital to making a game and it is important to have in order to describe your game project.



Image, game design exercise preview from lynda.com


How do we make one?


There are a variety of tools that could be used to create a GDD. These include word processing tools, visual tools like Powerpoint, or new web-based tools such as DunDoc. Each of these tools has their advantages and are a personal choice. Many of the examples shared via the internet are in Microsoft Word format. Romero Games(creators of Doom) favour a more visual tool such as PowerPoint. Whichever tool is used they should support the development of the game in an open and transparent manner.


What should be in it?


The GDD should be simple enough to read through details about your game design and concept. Schubert (2007), who was at the time lead designer for Bioware Austin, gave a GDC talk in about how to create design documentation, some of the most relevant elements include:

  1. Know your target.- Have a clear vision and understanding of what you want to make. Make sure your game is suitable and fits your target audience.

  2. Keep it short.  Keep it to the point and clear, the shorter they are, the easier it is to read, write, and maintain.

  3. Prioritize the design.  - Divide your game in order of importance e.g have a functional game. Concentrate on core mechanics and visuals, and then expand. 

  4. Illustrate. - Draw sketches of your plans that make it easier to structure and implement. Present what your game would look like as it’s important to have a clear idea of the visuals before you begin creating.

  5. Use user stories.- Describing the game through the player’s vision (Similar to what we did in the game vision statement).

Take into account the games users, their ideas may help develop future storylines or ideas.

  1. Invest in a good format. Take the time to structure your work so that it is easy to navigate.

  2. Use clear terminology. Don’t over-complicate the document. Make sure language is concise and accessible.

  3. Kill redundancy.  -Recycle your code - use variables, not hard code). Always reference the new section on your page to have a clean document. Avoid copy and pasting sections.

  4. Capture your reasoning - why did you make the choices you made? What led to that thought process?

References

Nachen, Lennart. 2014 Communication and Game Design Documents accessed 02/11/2020 http://acagamic.com/game-design-course/communication-and-game-design-documents/


Ferns, Shaun (2020) Readings Week 06 accessed 02/11/2020 https://cdmonline.ie/multidev1/reading-week-06/

 

 Gonzalez Leandro. 2016 How to Write a Game Design Document accessed 02/11/2020 

https://www.gamasutra.com/blogs/LeandroGonzalez/20160726/277928/How_to_Write_a_Game_Design_Document.php


Doing

  We are nearing the end of this semester and the book we’ve been working throughout the semester is in its final editing stages. This week,...