Bullet Devil: Attack of the Elements

For our third year game, we have decided to make an arena survival shooter where you, the player, will have to defend against waves of enemies while protecting your objective. You play as the Bullet Devil (our main character from our year 2 game), and you had to make an emergency landing on a nearby planet to escape from your enemies. Sadly, your landing was not the softest landing and the natives of the planet has gone to defend their land against the foreign creature, you! You must defend not only yourself but your ship as well, and defeat the waves of native aliens on the planet. These enemies are different from the usual enemies you face, they know how to control the elements and they use this power to try and eliminate you. You steal this power and empower your weapons with the elements to help defend against the attacks.

Gameplay Mechanics:
One of our main gameplay features we plan to implement in our game are the power of the elements in the enemies as well as the player's weapons. Each element will have a unique ability that affects the enemies and the guns the player wields. We plan to have a feature that evaluates the player on their progress, and depending on how well he/she is doing, the difficulty will slowly increase to create either more of a challenge for the player or to help the player complete the level.

Elements:
We plan to have 6 element types by the end of the year. Each element has its own unique ability.

- Fire: burns  the enemy and deals damage over time
- Ice: Slows the enemy down by reducing their movement speed
- Earth: Snares or immobilizes the enemy
- Air: creates a big wave and knocks back the enemy
- Light: Blinds the enemy (changes the A.I so the enemy is confused for awhile)
- Dark: Strongest and most deadly weapons in the game (can cause damage to the user)

Each element will have a counter. Opposite elements deal bonus damage to their targets but similar elements will deal reduced damage.
The current counters we have are:
Fire <--counters--> Ice (fire deal bonus damage to ice and ice deals bonus damage to fire)
Earth <--counters--> Air
Light <--counters--> Dark

This is a very simple counter mechanic in our game that players can easily get (unlike starcraft 2 where i have to learn all the counters after awhile, sad face)

Items and Pick Ups:
Each map will have a set of chests that spawn after a few waves. When the player opens these chest, they will be rewarded with either money or ammunition. Money will be used to unlock weapons and elements for the weapons they use. This gives an incentive to continue playing since there is a goal (unlocking every weapon).

Current and Future Plans:
What we plan to have for this semester is a good base with most of our mechanics implemented such has basic movement and shooting. Implementing the basic features will also have to be done such as collision detection/response, wave spawning and basic enemy AI. For next semester not only do we want to make a game look really nice with particles and shaders, but also many other features in the game, one which is co-op (obviously), another possible game mode, and also a way to expand on the player's arsenal. Our main focus though is to make a fun game that everyone can enjoy playing for many hours.

Scene Graphs

Scene graphs are a very helpful tool when design games. They are used to show the relationships between objects in the game. Scene graph form a hierarchy where certain objects can be parents or children of other objects. These scene graphs are a collection of nodes and edges that form a graph or a tree. These nodes are connected by their edges spatially or physically.  

This is a really basic example of a simple scene graph of a typical house. The nodes show what the objects are of the house and the graph also shows how each object is related to each other. The desk would be the child of the bedroom but the parent of the computer. Or the pillow would be the child of the bed but the pillow is not a parent at all. The house node has 3 children but no parents, which makes the house the root node. 

Scene graphs are great for managing objects in a scene but what else can they do? If a game has any type of animation with a object, there most likely a transformation happening during the animations. When using a scene graph, if a transformation is applied to a parent node, all its children will be affected by it. 

Here is another scene graph with the bones in a human hand/arm. When a transformation is applied to the parent nodes, the children nodes will all be affected by it. Try moving your wrist around, your fingers and the palm of your hand will also move to a new position. If you try moving the tips of your fingers, other parts of your body will not move. This means that the fingers are a child to the palm of the hand. Therefore when a transformation is applied to a parent node, all children of that node is also transformed. But when rotating, there is a certain pivot points that the object rotates around. Parent nodes will rotate in their object space but what about the children? Children nodes will also rotate around the same point as their parents because of the hierarchy created by the scene graph.

Just like for animations and transformations, shaders and effects can also be used with the help of scene graphs. With the use of scene graphs, effects can be applied to the parent and also the children of the parent. For example, if you were to use shadows inside a building, the game would implement shaders in the whole building (since it is the parent node). All objects in the building will also have a shadow, but objects outside of the building will not. This greatly helps with the rendering that the game has to do because it is not rendering shadows outside of the building. Also documentation will be cleaner since the programmer will not have to apply shadows to every single object in the building, just the parent node.

 Scene graphs are a core component of a game engine. It helps organize/manage objects in a scene, create certain groups and relationships between objects (hierarchy), group transformations and shader effects. 

Design Patterns

Design Patterns are templates implemented in many aspects of coding to create a more efficient way to reuse code. Instead of just copying and pasting code many times, with the correct design patterns, you could use one design pattern for multiple situations in your code. Design Patterns also show the relationships between classes or objects. It is always general and not for a specific language such as C++ so others can easily understand Design Patterns and implement it themselves. Reusing Design Patterns helps prevent issues that can cause major problems in the future.

Advantages of using Design Patterns:

• Speed up development process
• Help with debugging
• Increase readability of your code
• Increase the usability of your code

Some Design Patterns are:

Singleton:

The singleton pattern restricts instantiation of a class to one object which helps with when a single object is needed to coordinate actions to the system. A singleton only lets an object to have one instance of the class. Singletons have many uses since it only allows for a single instance. With a single instance, a singleton can be used for the renderer, mouse or even single sets of global parameters. 

Facade Pattern:

A facade is an object that provides a simplified interface to code. It is a manager class that manages others. The facade provides a single interface to a large collection of classes related classes. This makes a really solid pipeline for your code and makes how the classes interact with each other much more easily. The facade pattern reduces a number of interactions between classes in 2 different subsystems and instead allows the managers from each class to interact with each other, where they can then relay the data to the appropriate class. 

State Pattern:

State patterns deal with the objects state and use many switches or enums. The more states there are, the more confusing the state pattern can get. It gets even more troublesome when multiple functions must be shared between multiple states. A good way to help design this is to have a manager that controls the state logic and state switching. With shared functionality, it is always a good idea to use inheritance to solve your problems. When you want to add a new class to the system, it is easy to implement and doesn't require a lot of modify with other parts of the code. State patterns are great for controlling different states when using Artificial Intelligence (A.I) since you can switch between different states for different behaviours of characters. 

An example of this is a typical character in a modern game has multiple actions or behaviours such as idle, walking and attacking. The game needs to know which state is should be doing at a time. The manager takes care of which is the correct state must be used at a certain situation, and once the correct state has been selected the character will change its behaviour and perform the correct action.

Factory Pattern:

Factory patterns allows for objects to be created without specifying what the exact class of the object. Factory pattern defines a separate method for creating objects, where subclasses can override to specify the derived type of the object that is to be created. This method allows for the creations of instances of all types. This can be as simple as passing in a specific ID and have your factory/GameEntity class to create an object for you. These can be simple primitives such as spheres or squares to more complex objects such as meshes and models. New functionality can be easily implemented without changing much of the code. 

Basic Artificial Intelligence in Videogames

Artificial Intelligence plays a large role in video games where the players fight against the computer. They give behaviors and other features to objects in the game to produce the illusion of intelligence. Some A.I in modern games are done really well to imitate human behaviors. To create these illusions, game developers implement different algorithms to simulate intelligence in Video Games.

In most games, artificial intelligence can be broken down into three parts, Movement, Decision Making, and Strategy.

Movement:

Movement takes the decisions made by the program, and uses it to perform the specific motion. For example, a NPC can be just casually walking through a set path around the town, but when the player approaches the NPC, he/she will stop and “notice” the player. When the player moves out of range of the NPC, the NPC will continue walking along the path given.

Decision Making:

The game has to choose the correct decision based at any situation that happens in the game. This is where decision making comes in. When a situation changes, the A.I has to choose the correct behavior or action instantaneously. An example of this would be in Metal Gear Solid 4, where enemies would be doing their regular patrolling actions initially. But when they spot Snake or another enemy, they will change into a different action such as a seeking action. The game has to make the correct decision so the player will not notice any strange motions by the NPCs (unless intended). How strange would it be if instead of changing into seeking the enemies will change into a retreat action. A player would think that the enemies would be scared of you, but it would be strange. The enemies greatly outnumber the player, and can easily encounter the player. Without proper decision making it creates poor gameplay for the player to enjoy.

Strategy:

Strategy in Artificial Intelligence can be difficult or simple to implement. It is the behaviors of the game objects after the decision making has been made. Difficulty of implementing certain strategies depends on what the game developer wishes their game objects to perform. A simple strategy would be to have a single enemy attack the player. Generally implementing what a real person would do in that situation would be a difficult strategy to implement. The reason being is that people can think for themselves and are also unpredictable. Computers are very predictable and requires the game developer to write some sort of code so the computer can understand what to do. 

Here is a great example of what NOT to do when you want good A.I in your game. This video shows the lack of decision making and strategy in what a good artificial intelligence should have.

The Walking Dead: Survival Instinct