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

Sunday, 20 October 2019

Game Idea Research

Game Idea Research

For my last project blog I brainstormed some game ideas for my final game- an adventure game, a cooking game, a survival game and a jailbreak game. After heavy debating I have decided to further explore the survival game idea.

Initially I was going to do a classic deserted island survival game, but I have decided to spice things up a little bit by turning it into a fantasy based open world  survival game. The game would be in a fantasy setting full of unfamiliar, almost alien like plants and animals and surroundings. The surrounding area would be open and diverse to give the player opportunities to explore and decide where to set up camp; a dense forest, a mystical lake to fish and get water, a volcano area to gather things like stone and gemstones to make tools and weaponry.

A game I was inspired by and enjoy playing a lot that is of the survival genre is Don't Starve!

Dont Starve promotional image 
Source: Flickr


I was thinking of adding some hostile mobs to the game to add some challenge- but also allows the player to hunt and gather meat to cook. They would be further out in the land and not around the starting point so the player has time to prepare. A fun idea would be to have some tame able mobs to become pets that could fight for the player!

The fantasy element and unfamiliar flora and fauna could rise to add a hunger and poison mechanic- the player would have to cook things appropriately and keep in mind anything that could be potentially poisonous when eating food. Antidotes could be made using some flora to combat any poisoning.

Here are some game mechanics I feel could work for my game concept!

Hunger and Poisoning mechanic- since my game is a survival game, there has to be survival elements and risk to add challenge and realism to the game. A mechanic where the player grows hungry over the course of the game would be beneficial. For example, when the player is at a certain hunger level they cant regen health, and their movement slows, and their attacks grow weaker. When hunger reaches 0, it triggers a game over since the player starves. Poison would occur when the player doesn’t cook meats or certain plants; this would cause the player to gradually take damage over a period of time until it wears off or an antidote is taken. The game Minecraft actually has a mechanic a lot like this, and it goes into detail about it here!

A health system- Both player and mobs would have a certain amount of HP in their health pool which can lessen when attacked, when poisoned, or heat/cold damage is taken. Mobs die and drop meat when their health reaches 0, but when the players health reaches 0 it triggers a game over.

A temperature mechanic- To add realism to the game, I think a temperature mechanic could work. One of my planned areas for the game is a volcano, which would be hot, especially near the lava. The player would take damage if they stepped in the lava. The same goes for the cold, if a player for example gets in icy water they will take damage. Making pieces of armor that are heat and cold resistant could be a fun idea. One of my favourite games, The Legend of Zelda Breath of The Wild has a temperature mechanic, which you can read more about at this link!

Tuesday, 8 October 2019

Game Elements

Game Elements


My readings for this week gave me a lot of insight on not only what you should include when giving feedback and critique to a game, but also gave me an idea of key elements to think of when designing my own game.

There are so many elements to be considered when reviewing a game. What works well and what doesnt work well? Giving critique should go beyond saying “its fun" or “not fun". To properly give feedback on a game, I have learned that you must take into consideration the type of game it is you’re reviewing, and then looking at the formal and abstract elements of the game, analyse and test the game to give valuable informative feedback.


Rock paper scissors elements


One interesting point I have found from my readings is regarding the rules of a game (you can read it here). Though some games have defined rules, there are a lot of implied and unwritten rules in games. How far do rules have to be defined? How would defining rules benefit the player experience? The example I found to be effective of communicating this was the one regarding spawn camping in shooter games. I used to play a lot of shooters when I was younger, and I was definitely subjected to spawn camping. It is implied that you shouldn’t do this through the community- but it is not defined. Some consider it cheating. There’s no way for the player to really know since this rule has not been explicitly defined. Undefined and implied rules may cause arguments and confusion amongst players, so from my reading I will be sure to look at rules when giving feedback on games.

Another point I liked in my readings was that of information provided to the player (which you can read here). In games such as chess, the information about the status of the game is clear for the players to see- while in games like Clue the player is not given this information and must find it for themselves. Using this as reference can pose many questions when reviewing a game. Does the player have enough information to know what they’re doing? Or is there too much information which makes the game too easy? Does a lack of information benefit the gameplay? I have overlooked information in regards to reviewing games- but my reading made me realise how crucial it can make the player experience.

One reason why it’s so hard for us to properly give feedback on games is due to our lack of of a design vocabulary. As this article by Doug Church says, many professions and subjects have defined terminology for things within them, while game design lacks this. This is why people find it so hard to describe what a game is, and find it difficult to give feedback. This article discusses the Formal Abstract Design Tools (FADT) as a framework to discuss and build this vocabulary we lack. The discussion of Mario 64 along with the use of FADTs to discuss the game was actually very useful in my understanding. I at first found the concept a but confusing, but as the article went on and used the FADTs to discuss games it made more sense to me.

Overall I found these readings very beneficial in my understanding of exactly what a game is and how to review one. It helped me understand the importance of aspects I would have brushed away before, and it introduced me to the concept of FADT which I find will help me with giving feedback on games in the future.

Unity Tutorial 06

Unity Tutorial 06 Lesson 3.1 - Jump Force This tutorial was relatively easy to follow, however I encountered some coding problems...