#design-thinking

 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:

New Post has been published on https://awesome-people.newonline.help/traveled-the-world-to-design-awesomebox/

Traveled the world to design AwesomeBox

 Hi Everyone,

A bit of a break from the regular posts today as I’ve been thinking about how design can occur even when you don’t know it. In yesterday’s lecture, we were introduced to different balancing techniques used in games to ensure that the player gets a fair gameplay experience. At the end of lecture, we were told to think about what sort of balancing techniques could be used in the prototypes we made or even what techniques are used in games that we play. After taking some time to think about how I could implement balancing techniques into Orbital Malfunction, I realised that in a way, I already used such techniques in its design.

The techniques I am talking about is the use of transitive relationships, in particular, using direct costs and shadow costs. Direct costs are costs for using certain strategies that the player is explicitly told about while shadow costs are ones that the player are not explicitly told about. After reading about this, I realised that I had applied this to ensure that the shockwave emitter and EMP wave systems were balanced. The shockwave emitter has a direct cost in that when it is used, the system goes offline until it is turned back on again by the malfunction mechanic. The shadow cost however, is that the player is left exposed to enemy ships without any cover. The opposite is true for the EMP system, in its case, its use disables enemy ships with the direct cost being that it also disables all of the player’s ship systems. The shadow cost of this is that it leaves them temporarily defenseless to incoming asteroids. By having these costs, players need to think more carefully about how these using these systems will affect the state of the game world, and whether or not those effects will be positive or negative for them.

The implementation of direct and shadow costs on these systems was not something I was formally aware of but rather, sprouted from how I had designed the elements of my game to work together. It goes to show that design should be about having something function in a way that makes sense. The way something functions may seem obvious to the end user, but the process to getting to that stage is something that can vary in length for the designer behind that system or feature. There are probably several more design choices I have made that have some sort of official name and I would never know until I learned about them from somewhere or someone, the point is, it shows that I am starting to think more like a designer.