GMD1 DevBlog

Elemental Minecraft The idea  The idea was generated in order to fulfil the requirements of the project, which were to create an educational, science-based game aimed at children that are 8 to 12 years old. After a while of brainstorming and discussion, the group agreed upon a Minecraft style game that includes the combination of Elements, in order to increase the educational aspect. The idea came out of the inspiration of two pre-existing games, Minecraft and Little Alchemy. The Problems Up until this point, all games that the group created simply involved adding and manipulating GameObjects through the Unity editor or instantiating entire GameObjects through code from a prefab. For an idea like Minecraft, which was the basis of our world design, it doesn't take long to see how this form of world generation becomes an issue. A Minecraft style world is also known as a Voxel and as such will be called so from this point forward. Voxel world generation needs to be far mor

With the addition of a singleton SoundManager class from the previous week, it became apparent that Managers made accessing actions that were needed across multiple scenes far easier. Because of this, the group decided to localise more functionality into "Manager" classes. These classes can all be found under the "Assets/Prefabs/Managers" folder in the github repository posted at the end of this blog. The functionality that was moved into "Manager" classes include Sound (mentioned in last week's blog post), EndGameManager(The functionality behind when a game is over, such as number of lives reaching 0 or the player reaching the end of the game), LevelLoader (Functionality to progress the player from one level to another, or one scene to another), Button Manager(Handles the buttons on the Main Menu). Each of these classes are singletons which are initialized when the Main Menu is loaded and persist throughout gameplay using the "DontDestroyOnLo

This week the group were tasked with tackling some advanced scripting topics shown in the following image: The group primarily focussed on improving game functionality for this week, so that the game was playable and looked good. This meant an overhaul of the inputs for player movement and the addition of a "Boss Battle". The chosen boss for this battle is a witch, that has three layers of animation, one for hovering, one for horizontal movement across the screen and the last for casting a spell. While no AI pathfinding was used for this battle, a simulated pathfinding was used for the projectile that the witch releases when casting a spell, which moves towards the player by having a small force applied on it in the player's direction, if this spell hits the ground instead of the player then an enemy is spawned that follows the same logic of pathing towards the player. Gameplay testing and all of the attached scripts can be found at the GitHub

This week of our GMD session finished with workshop 3 assignment in which we are supposed to create a 2D game using all of the knowledge that we have gained from our previous projects, plus on top of that we were introduced to topics such as sprites(pixel art), different kind of animations used in 2D environment, 2D physics, how to handle user's input etc. The main idea was to create a local multiplayer game, consisting of 2 characters, who co-operate with each other to shoot down enemies standing in their way as they are trying to reach the end of arcade-based level jumping through different obstacles. We have decided that instead of creating our own sprites, because none of the group memebers have experience with pixel art and all of the concepts in regards to this topic, we are going to take the advantage of having vast amount of sprites atlases(collections of sprites) available online, ready to be downloaded for free. The main website from which we have decided to download

With this week came the conclusion of our 2D games project, where the team focused on player movements and logic to make the game playable, including things such as keeping score, pausing the game, adding a number of lives to the UI and firing projectiles in order to be able to kill enemies, each of which will be covered in this post. Keeping score and number of lives: This was accomplished using a simple UI overlay to the game and setting it on a layer that was drawn after the rest of the game objects, with basic collision logic for the projectile so that if it kills an enemy then a score is increased by x, and collision logic for is a player runs into an enemy. The projectile is spawned at an offset to the player's current location, which is also rotated with the player is running in the opposite direction, to ensure that a projectile always follows the forward direction of the game object it is attached to. An example of this is as follows: Pausing the Game: Pausing

As we were moving closer towards our deadline for assignment introduced during workshop number 2, there were still some important elements left to implement in our small gaming project called Unity-Chan. These are as following: Multiple Lights, Particles/Particle System, Audio (background music and effects) and animations other than character animations (optional). Particle System Upon our group discussion, we have decided that the best spot, where to put our particle system and what effect it should have is a sparkling effect added between the two swinging hammers from the ceiling which hit each other and therefore a collision occurs which would create such effect. The sparking was created based on the following tutorials provided by Unity but also Youtube Unity enthusiasts       - https://unity3d.com/learn/tutorials/topics/graphics/particle-system?playlist=17102       - https://www.youtube.com/watch?v=MYU1vBcUkfw       - https://www.yo