#chapter-readings

 Hi Everyone,

Some of you reading may or may not have been aware that many of the blog posts I’ve been writing are for an assignment where I must reflect on my progress throughout my unit IGB220: The Fundamentals of Game Design. This semester and year in general has been pretty rough for me however, this unit has been a lot of fun to do and I find what I’ve learned from it extremely valuable in my journey to become a game designer. So I thought in this blog post, I would go over one of things I improved upon from this unit: communicating my design ideas. I might also do other posts like this in the weeks to come covering other things I have found valuable for IGB220 so watch out for that.

By far the most important skill that I have developed/refined is my ability to communicate my designs. In Chapter 14 of Game Design Workshop, Fullerton (2019) talks about how being able to share the vision of the game you are working on with those you work with is a crucial skill if you wish to work efficiently and well as a team.  Having only worked on games by myself prior to this unit, with no real opportunity to present my ideas to anyone else, I didn’t really have any need to record my ideas in any form other than in my head or just quickly jotting them down on a piece of paper; a practice I now realise is not that good.

Fullerton (2019) in Chapter 14, continues to discuss that a good way to communicate your designs is through some form of visualisation, as it’s often simpler way of representing your vision rather than describing the game with pages of text. While I didn’t know it at the time, this unit has taught me to do this in many ways. Primarily, the elevator pitch posts I made for each of my workshop prototypes always contained a gameplay concept sketch which could often be the only thing that would need to be looked at to get the idea behind the game. 

Espionage Tactics Gameplay Concept Sketch

Orbital Malfunction Gameplay Concept Sketch

Hyperblast Gameplay Concept Sketch

These sketches helped me greatly in developing my prototypes as I found myself often looking back at these concept sketches as reference to what I was aiming to create. Had I not made these sketches, my prototypes may have lacked direction and would not have turned out so well.

The whole of assignment 2 in fact, where I had to design a one sheet and one page extended upon what I did for the elevator pitch posts in order to communicate enough on just two documents that a team could look at them and use it to create the game.

Hyperblast One sheet

Hyperblast One Page

This assignment was a good exercise on my ability to decide what elements were crucial/core to the game. These two documents went through many iterations as for the one sheet, I struggled to find how I could communicate the gameplay of Hyperblast in a still image and for the one page, I struggled to only fit what was necessary to develop the core of the game. I often found myself repeatedly asking myself what are the core elements of my game as I tried to hone down on what exactly I should be putting on these two documents. In the end, I felt I successfully communicated what my vision for Hyperblast was however, I feel I could’ve communicated a bit more about the game vision on the page had I used the space of it a bit better; a point that the person who marked my assignment agrees with.

The elevator pitch sketches, one sheet and the one page were not something I was particularly familiar with using before this unit. After working with these documents however, I see the value in using them to visualise your ideas as I now feel that they are something that I will continue to use to flesh out my ideas both for my own benefit and to communicate with those I work with.

Thanks for reading!

References:

Hi Everyone,

Haven’t posted in a while and realised that I only went over how I thought play-testing for Hyperblast went but not about how what I learned developing it; which turned out to be a lot actually.

In my previous development cycles, I felt that I was trying to just create something that looked and felt good to play rather than create something that was designed well and was fun to play. I’m not trying to discredit the work I did on those previous games, I still find elements of them fun, but my stubbornness to stick to my original vision for those games led to them not expanding past those initial ideas. In a sense, I was not chasing the fun of the game.

All the way back in Chapter 1 of Game Design Workshop, Fullerton (2019) recommends that when developing a game, use a ‘playcentric’ process. To summarise Fullerton’s playcentric process: you come up with an idea, formalise it, test it, if the ideas work you continue to refine it, if the ideas don’t work then go back and see and think about how that idea could be changed so that it does work. Going into the development of Hyperblast, this was the mindset i had.

My initial vision for Hyperblast was that it would be a very simple bullet hell / shoot em’ up (I had issues with scoping my ideas properly in previous development cycles so I decided to go with something a bit more simple this time around). The player would just use the arrow keys to move left and right and press space to shoot.

The ship weaving between enemies in the sketch was just a stylistic choice to represent gameplay but would turn out to inspire me later on. 

When I started prototyping Hyperblast, I found the gameplay to be overall bland, that the game had no interesting mechanics and overall it would not engage the player. I decided to go back and look at how I could change the initial idea of my game a bit to make the game engaging. In Chapter 4 of Game Design Workshop, Fullerton (2019) talks about how challenge in games is one of the largest forms of engagement, as it induces players into a ‘flow’ state. Fullerton (2019) then detailed what elements could cause this ‘flow’ state and of that list, two stuck out to me: 

A challenging activity that requires skill

Concentration on the task at hand

Evaluating my prototype, I found my prototype had none of these. The type of gameplay I was creating could date back to some of the oldest games back during the arcade days and had nothing special to differentiate it from them. My original sketch inspired however, as when I looked at it again, I thought what if the player was constantly moving and only had control over which way they moved? I implemented this idea and the game started to become more fun. The player would always have to concentrate on making sure their ship was moving the right way and the enemies provided a challenge in that the player would have to be skilled with the movement mechanic to dodge them. I added more elements to the game to support this mechanic and eventually got the prototype you can see in the video below:

While I was overall proud with what I came up with in the given time frame. I had concerns that because I spent so much time trying to make the core mechanic of my game work, I neglected designing some of the systems that would support it, particularly the progression systems of the game. This would turn out to be true as many play testers reported that while the game’s core mechanic was interesting, there wasn’t much to do once they had encountered all the enemies and the game felt repetitive after a while. Fullerton (2019) in Chapter 5 of Game Design Workshop makes a point in saying that the elements of a system do not exist in isolation and must work together in order for the system as a whole to work. Because I neglected one element of my game, the other elements suffered because of it.

What I can take from developing Hyperblast is that having a clear plan from the start will allow you more time to develop and refine the ideas you intially started with. I mostly think about the ideas I come up with in my head and develop them from there, only formalising them when I have something tangible to play or interact with. I’ve learnt in retrospect that this is a bad practice and I would benefit with doing other forms of idea generation and prototyping detailed in chapters 6, 7 and 8 of Game Design Workshop  such as mind maps, paper prototyping and single mechanic prototypes beforehand. I still feel there is a lot of potential to expand upon what I have created for the prototype of Hyperblast which is why I have decided to use it as my game for Assignment 2, where I will make a one sheet and a one page for Hyperblast.

Thanks for reading!

References:

Hi Everyone,

In my last post, I focused on talking about what I learned from the play-testing of Orbital Malfunction but not so much what I’ve learnt from developing Orbital Malfunction. So in this post, I’ll be going over just that.

As this was my second time making a game in GDevelop, I felt a lot more prepared and organised making Orbital Malfunction, and because of that I was able to have a larger scope developing the prototype. I discovered that events could be sorted into groups and using this, I was able to organise my events neatly which was a problem I had in my previous development sprint that caused me to not develop Espionage Tactics as much as I wanted to.

With the events more organised, I was able to fully implement the core gameplay of Orbital Malfunction that I intended, at which point, I decided to see what else I could do to make my prototype better. 

In the lectures and in Chapters 7 and 8 of Game Design Workshop (2019), we were told that audio is not necessary part of the prototyping process as the main purpose is just to test if the core gameplay loop and elements of your game actually work. With Orbital Malfunction however, I felt that audio cues were an important aspect of gameplay that was required in order for the player to get all the information required to play properly. I found some free sound effects which you can find here (and while I’m at it, some pretty awesome music tracks for the game) and added them to Orbital Malfunction. This decision ended up being a good one,  as play testers who did not play with audio did not perform as well as those who did.

Not all things I tried to do to make my prototype went smoothly though. While I was more organised with my development process, I was still limited by the capabilities of GDevelop’s event system. The limitations of the engine made it harder than I thought to implement the ship systems of and because of that I had to change how some of them worked. The missiles instead of blowing up asteroids within a radius just destroys multiple asteroids without being destroyed itself and the shockwave emitter destroys all asteroids completely instead of splitting them up into smaller asteroids. This comes down ultimately to the fact that I am still discovering the inner workings of GDevelop, and due to this, my ability to scope my ideas to what is suitable for the engine is not as good as I want it to be.

I have admitted in previous posts that GDevelop does make some things more convenient than other engines. A lot of the behaviours available such as TopDownMovement and Pathfinding allowed me to implement player and enemy movement a lot easier and faster than in other engines. I also learnt how to use GDevelop’s post processing effects, which allowed me to take the resources given to us in the workshop and spruce it up a bit.

There’s a lot more I need to learn about GDevelop in order to become better at scoping my game ideas but I definitely see an improvement from my last development sprint.

Thanks for reading!

References:

Hi Everyone,

Earlier this week I play-tested Orbital Malfunction during my workshop and was pretty happy with the results. Overall, the people who play-tested Orbital Malfunction really enjoyed playing it and were also able to provide some valuable feedback. After taking some time to synthesize my notes, here are the main points I got from play-testing:

Positives:

The game was enjoyable and fun to play

The concept of the game was interesting, the malfunction mechanic of the game was unique and was what made the game fun.

The game’s audio and graphics were really polished

What Could Be Improved:

Some of the systems functions were unclear as well as how to use them

The malfunction mechanic sometimes made the game boring (e.g. when the blasters were turned off and you couldn’t shoot asteroids/enemies)

Some play-testers did not understand how the malfunction mechanic worked and needed it to be explained

Sometimes when the malfunction mechanic triggered it would go unnoticed*

* Play-testers who reported this did not play with audio.

Most of the improvements listed are aimed at the ‘malfunction’ mechanic which I’m satisfied with as going into play-testing, that was the main thing I wanted to test. In Chapter 10 of Game Design Workshop, Fullerton (2019) states that you shouldn't try and fix everything in your game at all once but instead, focus on trying to improve one aspect of your game, particularly, the core gameplay of your game and if it fits your original vision. As the malfunction mechanic is what my whole game revolves around, getting feedback on it was the most important thing for me and why I decided to test for that.

The feedback showed me that while it was an interesting and unique mechanic, it may have not been as fun or fine-tuned as I hoped. Because of the nature of the mechanic, players found that it sometimes took the fun away from the game as they would no longer be able to shoot or move and as a result, not be given much to do. Testers also found that how to use the systems could have been explained better as they were confused as to how some worked.  On top of that, some testers needed the malfunction mechanic explained to them as they did not understand why they could no longer shoot or move (there was a help section on the game menu that explained the mechanic, but some did not read it first and instead went straight into playing). This feedback tells me two things that need to improve about Orbital Malfunction:

The individual systems of the player ship all need to be engaging so that when the malfunction mechanic triggers, the game remains engaging no matter which systems are online, not just when certain systems are online.

The malfunction mechanic and the ship systems related to it need to be explained within the game in a clear and intuitive way that does not rely on them having to read a help section to gain a basic understanding of them.

The last thing I want to talk about is some improvements I could make to my play-testing process. The last piece of feedback for improvement that I got was that the malfunction mechanic sometimes went unnoticed and play-testers who reported this suggested some sort of audio or visual cue to alert the players attention when a malfunction occurred. These play-testers did not play with audio however and if they had, they would have known that I actually did have an audio cue when the malfunction mechanic triggered. This was partly my fault as I had not specified to the testers beforehand that the game had audio and as a result, they did not have a completely accurate experience of the game. For next time, I will have to ensure that the tester is aware of what elements are in my prototype so that they are able fully experience my prototype and that way, I will be able get more valuable feedback on issues in my game that I was not aware of.

Thanks for reading!

References:

Hi Everyone,

In this devlog, I want to talk about how I took the original game of Asteroids and adapted it to make Orbital Malfunction. 

This week we started work on our next game prototype. We followed a tutorial showing us how to (partially) make Asteroids in GDevelop and from there we were to create a game inspired by Asteroids. In my last blog post I talked about my elevator pitch but the process I took to get there required me to analyse the structure of Asteroids and what makes it unique from other games. Drawing from Chapters 2 and 3 from Game Design Workshop by Tracy Fullerton (2019), I decided to analyse Asteroids by the formal elements that make up the structure of the game:

Screenshot of Asteroids (TechnologyUK, 2020)

Players

Asteroids is a single-player game

Objectives

Accumulate as many points as possible by destroying asteroids and enemy saucers 

Procedures

Player can rotate ship

Player can thrust forward in the direction they’re facing

Player can shoot in the direction they’re facing

Rules

Player dies if they are hit by an asteroid, saucers or saucer projectiles

Saucers die if they are hit by an asteroid or player projectiles

Objects can wrap around the screen edges

Asteroids break into smaller asteroids when destroyed: Large Asteroid > Medium Asteroid > Small Asteroid

Resources

Player has three lives

Player has an infinite amount of projectiles

Conflict

Number of asteroids increases as game progresses

Boundaries

Player is confined to the game window but can wrap around to reach the other side of the screen

Outcome

Player wins when they reach the maximum number of points

Player loses if they are destroyed by an asteroid, saucers or saucer projectiles

After breaking down the formal elements that make up Asteroids, I had a clear idea on what I had to implement in order to have a base Asteroids prototype that I could expand upon and adapt. From there, I thought about what I could add to make the game more interesting and unique. I started thinking about another game I made recently called Toggle Arena and the mechanic in that game.

In Toggle Arena, the player must survive as long as they can within an arena filled with enemies with the catch being that at a random interval, different settings are turned on and off, changing how the player must combat enemies in order to survive. Inspired by that idea, I decided to have a similar mechanic called ‘Malfunction’ in my Asteroids-inspired prototype where the players has a bunch of different systems that malfunction on and offline, requiring the player to adapt to the conditions of their ship as its malfunctions and thus, Orbital Malfunction was born.

Having a solid idea on what game I was making, I got to work implementing all the formal elements that make up Asteroids in order to have a working prototype, the result of which you can see below:

One thing I changed however, is the way the player moves. Instead of thrusting forward in the direction the ship is facing, the player is able to move in four directions thanks to GDevelop’s TopDownMovement Behaviour. Using this behaviour, I was able to implement a system where if a player tries to move on the axis opposite to the one they are currently on, it makes the ship strafe dodge, allowing for more tight movement which will be needed as I intend for Orbital Malfunction to be much more fast paced than Asteroids.

That’s all for this devlog. In the next devlog, I will go over my actual implementation of the ‘Malfunction’ mechanic.

Thanks for reading!

References:

  Fullerton, T. (2019). Game design workshop : a playcentric approach to creating innovative games (Fourth edition.). CRC Press, Taylor & Francis Group.

Hi Everyone,

Day 2 on working on my Espionage Tactics platformer prototype and decided to focus on implementing a new tileset, the crate/barrel mechanic and the laser traps. After a few hours of work here is the result after today:

Changes

New Tileset

The artwork used in the last version of the prototype was provided to us during the workshop but it didn’t really fit the spy / top secret base theme I was aiming for. I decided to use the 1-Bit Platformer Art Pack from Kenney Assets which I found here.

New Player Sprite and Animations

The art pack also came with player character sprites. With these sprites, I was able to create individual animations for its idle, running, falling and dead states, allowing the player to more clearly understand the movement of the player character. 

All sprites now fit within 32x32 pixels which made it easier to utilise the grid system to place level geometry, allowing for better level design. This also made the player character more suited for platforming as its movement was smoother, controlled more tightly and has a better jump arc that fits the dimensions of the level. 

Additions

Lasers!

While I’ve already added  basic enemies, I thought I should implement at least one of the ‘surveillance traps’ that I had detailed in my elevator pitch. I decided on implementing the moving laser traps as it seemed the easiest to implement. The lasers emitter moves from side to side on the roof and if the player touches the laser they die. While play-testing however, I found I would accidentally run into the laser as I forgot how far they could move so I also added in warning signs that indicate the movement range of these lasers.

The Barrel Mechanic

The player needs a way to get passed the laser unharmed, so I implemented the ability for the player to hide in a barrel. Originally it was going to be a crate but the art pack did not have a crate sprite so I used a metal barrel sprite instead (which seemed to fit the aesthetic better anyway). The player can hide under the barrel by pressing the ‘c’ key but  can’t move under it. They are immune from being detected by surveillance traps but can be damage if touched by enemies. This could have the potential that If used in combination, the player would have to skilfully balance between dodging enemies and evading surveillance traps.

Future Goals

The prototype definitely needs some work. The original elevator pitch for the game and one of its selling points was the fusion of stealth-puzzle gameplay. After reading, the Game Design Workshop by Tracy Fullerton (2019), specifically Chapters 7 and 8, prototyping is definitely a good way to see if the fundamental mechanics of your game actually work and are fun. I feel not enough has been implemented to show the game play loop I’m trying to create, so I may add more surveillance traps such as the security cameras and patrol bots. I do have to be careful however, as Fullerton (2019) also states that spending too much time developing prototypes defeats the purpose of them. So if I implement a few more features and it doesn’t work to make the gameplay experience I want, I might have to go back to the drawing board.

Thanks for reading!

References: