Mark Auman's Game Development Blog

Hi Everyone,

This blog post will be a part two to my previous post where I reflected on the prototypes I made over the course of the semester. In this post, I’ll be wrapping up my blog posts for the IGB220 unit by going over what I’ve learned in general over the course of this semester.

GDevelop and Prototyping Sprints

Before this unit I had never heard of GDevelop, having stuck mostly to more well known engines such as Unity. Overall, I think GDevelop is a great tool for making quick prototypes and seeing if your initial ideas work; which is pretty much what made it perfect for developing the prototypes that we made over the course of this semester.  The engine comes packed with a bunch of premade behaviours that made setting up the platforming for Espionage Tactics, the enemy AI in Orbital Malfunction and handling out-of-screen objects in Hyperblast extremely easy.

Beyond that however, I think I’d stick with something like Unity to make a game because, as I’ve detailed in a quite a few posts, its convenience can also be irritating. I’m very much used to the systems found in Unity and other engines such as prefabs, a proper UI system and traditional scripting; all things absent within GDevelop (JavaScript can be used but the ability to make objects with different script components is more so what I’m referring to). It makes managing larger games within GDevelop very difficult and I often found myself in the earlier prototype sprints spending more time making sure that events were consistent amongst different scenes than developing the actual game.

As I detailed in previous posts, I learnt how to properly scope my ideas and learnt how to better use GDevelop over time, however, the difference it makes is minimal. I do acknowledge that GDevelop is probably a better introduction into making games than Unity as the event system is more accessible (at first), but I think many will find pretty quick that they will be limited in some way by it. While I am happy with the prototypes I made, I can’t shake the feeling that I could’ve taken them further had I used something else.  Here are some videos of each of the prototypes in their final states (at least for now ;) )

Espionage Tactics Gameplay Video

Orbital Malfunction Gameplay Video

Hyperblast Gameplay Video

Assignment 2: The One Sheet and One Page

The One Sheet and One Page were a good exercise in learning how to communicate the ideas of my games in a succinct and effective manner.

The Hyperblast One Sheet

The Hyperblast One Page

I found it challenging at first because there were so many things I wanted to put on both of these documents but didn’t have enough space. The reason for why I struggled with this is because the purpose of these documents was not to put as much as you could on them, but to detail as clearly and concisely as possible, the core elements and ideas of your game so a development team or some other stakeholder could get a good idea on what it is you’re trying to create. I didn’t get this at first, thinking if I didn’t include this or that, then people wouldn’t get the whole picture. But I’ve learned that games are not set in stone from their original design, they change as the development team discovered what works what doesn’t and that is all part of the prototyping and playtesting process. Understanding that, I restarted and listed what I felt were the core aspects of the game and that was what ended up making up the two documents you see above.

The One Page and One Sheet were something that I thought wouldn’t be as helpful as they were, and are definitely something I will use with future projects when given the chance. They are extremely helpful in getting your ideas across with other people who might work on your game which was the case when I went on to continue developing Hyperblast for the group assignment.

Assignment 3: Prototyping and Playtesting Report

I was taken by surprise by how well my group members and I worked together given my experience with group assignments this year which I’ve discussed in previous posts. As I’ve also discussed in previous posts, I think this boils down to the fact that we had a good idea on what each of us were capable off, and divided the tasks we needed to do accordingly. Overall, the development of the group prototype went really well.

Hyperblast Gameplay Trailer

Playtesting turned out to go pretty well too. We are able to get consistent findings amongst our playtesters which lead to us being able to easily identify the key issues within our game and in a way, verified that we were doing something right with how we were conducting our playtesting sessions. A lot of these issues were something that we missed as the developers of the game and proved how invaluable it is to get other people not associated with the game to play it in order to see what works and what doesn’t with unclouded eyes.

Overall, the whole process was a good learning experience and something I’ll take into account when working on future projects.

Assignment 1: The Blog

Finally, the blog itself has been a lot of fun to do. Having never used Tumblr, no less written a blog, a lot of this was quite new to me and I found it difficult at first to reflect on my progress throughout this unit; hence why a lot of my first few blog posts are focused on development rather than reflection. As I progressed through the unit however, watching the lectures and reading through Tracy Fullerton’s Game Design Workshop, I got more confident that I knew what I was talking about and actually found the ability to write how I felt I was going within the unit a good way to track how I was progressing.

Sadly, this will be my final post on this blog for the IGB220 Unit, and while it is the end of those posts, I may continue posting about future projects that I work on as I’ve rather enjoyed having a place where I can write about what I’m doing. I guess we’ll just have to wait and see.

Hi Everyone,

It’s finally the last day of the semester! I’m just about finished wrapping up on final assignments and just need to submit them so I thought a good way to wrap up these blog posts would be to look back at what I’ve done over the course of this unit. I’ll split this post into two parts, with the first discussing the game prototypes I developed in GDevelop and the second discussing the what I’ve learned from the unit in general. To start off, going back to the beginning of the semester, the first prototype I developed was Espionage Tactics

Espionage Tactics

Looking back, Espionage Tactics was a pretty rough prototype but it taught me a lot about the prototyping process that would end up helping me later on in the semester. The initial idea behind it was for it be a stealth-based puzzle game where the player would have to utilise a variety of mechanics and tools in order to complete each level.

Translating this initial idea into an actual prototype turned out easier said then done. Having no previous experience with GDevelop, I was pretty ambitious thinking I could implement everything I set out to in my original pitch. My inexperience led me to have to scope down the initial idea quite a bit in order to have something I considered playable. I also had to learn to deal with GDevelop’s event logic system, something that is supposed to be more accessible than traditional coding however, I found the system to become a hassle to manage once the logic of the game became more complicated.

Snippet of the Events for Espionage Tactics

The result of this was that I would end up spending more time trying to make sure code was consistent amongst all the scenes as the events were not shared amongst them and because of that, changing a common event in one scene would required me to change it in the others.

Overall Espionage Tactics was a good exercise in learning how to scope ideas properly, iterate on them and deal with the limitations of the tools available to you. I was then able to take what I learned from this prototype and use it to develop my next prototype, Orbital Malfunction, faster and more efficiently.

Orbital Malfunction

Orbital Malfunction is perhaps my favourite prototype that I made however, it taught me an important lesson about making sure the mechanics of your game are easily understood by the player. The initial idea for the game was that the player would have to survive as long as they can within an asteroid field, however their ship is suffering malfunctions, turning on and off different ship systems.

Implementing these systems so that the game always stayed interesting and fair was a bit complicated which I detailed in a previous blog post. While it made sense to me how these systems worked, that was from the perspective of the designer of the game, not the player. I found during playtesting that because of the nature of the malfunction mechanic, players could easily get confused about what each system did as they would turn on and off; not giving them enough time to understand what each one did. While I had a help menu that explained what each system did, the majority of playtesters did not look at them. They shouldn’t have to anyway as I feel the systems could’ve been explained in-game somehow; perhaps turning only one system on at a time at the start of the game to introduce them to each individually would have helped.

While the gameplay turned out quite well and people who playtested it found it quite fun, the initial confusion as to how the malfunction mechanic worked was a bit of a roadblock in terms of the playability of the game. From this, I learnt that the core mechanics of your game need to be clear and understandable, otherwise the systems built around it will suffer. Perhaps I would’ve benefitted from doing some paper-prototyping like Fullerton (2019) discussed in Chapter 7 of Game Design Workshop. Had I done so, I probably would’ve identified issues with the initial idea earlier on and seen that the malfunction mechanic was a bit too complicated. With my final prototype, Hyperblast, I focused on creating a mechanic that was simple, and was very clear to the player how it functioned.

Hyperblast

The Hyperblast prototype is the most refined out of the three as it was used for the development of Assignment 2 of this unit and was also further developed for Assignment 3. Inspired by classics such as Space Invaders and Galaga, Hyperblast was intended to be a shoot ‘em up where players would take on waves of enemies. The original idea was that the ship would move just like they did in those games, with full control over movement however, as I developed the prototype, I found the gameplay boring as the game wasn’t doing anything interesting and there was no unique mechanic that it was built around like the previous two.

Taking a look back at my original concept sketch for Hyperblast, I wondered how making it so the player had less control over the movement of their ship would  change up gameplay. Sure enough, the change to gameplay by making it so pressing a key made them travel in one direction until they pressed the key to make it go in the opposite direction made it so that the player had to always be actively engaged with what was going on on-screen. It’s a bit hard to explain through text so here’s a video of the gameplay of Hyperblast.

I feel with the way I was approaching development for Hyperblast, I was starting to achieve what is the supposed outcome of  this unit and the prototyping and playtesting process, following the fun. I learnt through this prototype that your initial ideas don’t have to be your best ideas and often they aren’t, but they can lead you to better ideas if you can deduce what about those initial ideas made them work. I also learned to work in a team better when working on the prototype for Assignment 3. I was able to communicate my ideas for where I wanted to expand the prototype pretty easily, they were able to help me see what about the prototype worked, and we all contributed to turn the original prototype into something that was much better.

Overall, I’m extremely happy with the game prototypes I made this semester. It was fun to learn how to use GDevelop (despite the event system) and being able to get feedback on whether my games were fun was invaluable. Learning how to prototype my ideas was also an invaluable skill I gained, as before this, I wouldn’t be as considerate of whether the mechanics of my game idea worked and would dive head first into development. With this new knowledge, I feel I can make games more efficiently and better.

Thanks for reading!

References:

Hi Everyone,

It’s been a week or two since my group and I wrapped up on playtesting Hyperblast for Assignment 3 which has given me time to reflect on more than just how the playtesting process went. During playtesting, my role was to take down notes on comments players made about the game as well as anything else I observed as they played. Despite my role being so focused on observing what the playtesters thought, I have to admit that I still don’t really know if they found Hyperblast to be a fun game,

Fun is something that is not easily defined however, as Fullerton states in Chapter 11 of Game Design Workshop (2019),  “fun is subjective, contextual, and entirely up to personal taste”. I’d say it would be reckless of me to come to any definitive conclusion as to whether players would find Hyperblast fun based off the six short playtests we did. Fullerton (2019) continues discussing in Chapter 11 that it might be hard to for playtesters pin down what exactly makes the game they are playing fun so being able to identify the possible fun factors of your game could help in asking playtesters the right questions to confirm whether those factors are what make the game fun. While I feel I thought I had a good idea on what made Hyperblast fun, perhaps analysing it in the way Fullerton does may allow me to make better conclusions on whether playtesters found Hyperblast fun or not. 

Fullerton (2019) discusses in Chapter 11 a few things that can make a game fun with three of them sticking out to me: challenge, reaching and exceeding goals, and making interesting choices.

Challenge

In Hyperblast, the main gameplay consists of the player constantly moving side to side as they try to shoot down enemies as they pass by. Here’s a video as its much easier to visualise the gameplay that way:

Much of the challenge of the game comes from the movement mechanic. Because the player is continuously moving, they must always be aware of their surroundings and engage with the game if they wish to progress. I observed that many of the playtesters found it difficult at the start playing the game as the movement mechanic was something they needed to get used to. After a few minutes of playing however, the majority of playtesters adapted to the movement mechanic. I would say that this a good challenge as players are faced with a unique mechanic, must learn to adapt to it, and are given a sense of mastery as they better adapt to it.

Reaching and Exceeding Goals

The goal in Hyperblast is to reach the highest wave you can. In the prototype, there are only a few waves implemented so the goal is more so to reach the first boss wave, where the player fights the Overseer,

Playtesters were not explicitly told about the boss however, when told about it, it gave them something to strive for and continue playing the game. Even then, some playtesters commented that what kept them playing the game was that they wanted to see new enemies in the later waves which is a good sign that players were enjoying the game. This alleviated my initial concerns that playtesters may not be interested in progressing through the game if all they encounter is more enemies but the variety and different functions these enemies have seemed to be enough to keep them engaged,

Making Interesting Choices

Fullerton (2019) discusses further in Chapter 11 that player choice is important as it allows players to feel they have an impact within the game but, it is important to note that it only does so when the choices have the potential to have consequences or provide an advantage to the player. This was the aim of the ship and weapon customisation feature in Hyperblast.

The idea was that players would select  different ships and weapons in order to experiment and find their play style. The different ships would alter their movement capabilities while the different weapons would alter their combat capabilities. In retrospect, this could not be achieved as I feel the different weapons and ships are not different enough to change up gameplay and therefore makes the decision not that impactful. I noticed that playtesters did prefer a certain ship or weapon but the way they played stayed relatively the same, so at most the aspect of customisation only allowed for minor changes in the game state. This may be a problem as the inclusion of a customisation feature implies to the player that by customising their ship, they can change how they play the game which includes the challenge and their ability to reach and exceed goals. In the current state it is in however, the Hyperblast customisation feature does not provide this and in my eyes, makes it not as fun.

Conclusion

I think that the challenge and goals presented in Hyperblast are what make it fun. The customisation feature of the game however, brings the fun down as it doesn’t deliver on the promise of changing up the gameplay experience. In hindsight, perhaps I did not put enough consideration into the necessity of a customisation feature nor did I consider whether the choice provided actually was impactful for the player. In the future, I will need to consider more in depth the purpose of different elements of my game’s system if I am to properly understand what it is that makes my game fun and what doesn’t.

Thanks for reading!

References:

Hi Everyone,

We’re coming to the end of the second last week of the semester, making it just over a week before assignment 3 is due. Our group has worked pretty smoothly and because of that, the only thing left to do is edit and proofread our prototype & playtesting report, finalise our game prototype and make sure we are all happy with it before submitting. So, I thought now would be a good time to talk about how doing this assignment went as well as what I learnt from it.

To start off with, I’m quite surprised how smoothly this assignment went, especially considering it was group assignment. Due to COVID-19, the majority of uni work this year has been online, including group work. Based off my previous experience with group assignments this year, I was not expecting this assignment to go too well. Despite all this however, I feel our team did very well on this assignment.

I think why we worked so well together is due to a number of reasons. For one, the fact that for the majority of this unit we have been developing game prototypes and playtesting them with each other allowed us to gain a good understanding of what the limitations of GDevelop were and what each person was good at doing. This allowed us to establish early on what our tasks and each of our roles would be when working on this assignment which really helped as it allowed us to have a clear idea on what each of us needed to do each week and ensure we contributed equally to the project. Throughout this assignment, our group also maintained a good line of communication, holding meetings every Thursday to discuss what tasks were done, what needed to be done by next week and playtesting our game. We would also keep each other updated on any changes made to the prototype or documents and any ideas we had for the assignment. From this, I’ve learnt that good teamwork not only requires good communication, but also requires that there is a clear understanding of the capabilities and roles of each team member from the get-go.

Not everything went smoothly all the time and as such, we had to adapt to the circumstances. In particular, we had trouble figuring out how exactly we could work on the game prototype at the same time or ensure that changes we made would carry over across the different versions we were working on as GDevelop has no built in cloud-based/ collaboration services. One of our teammates was unable to access GDevelop at home so they worked solely on the playtesting materials while my other teammate and I were responsible for developing the actual prototype. In the end, we worked out a system where one of us would work on the prototype, implementing a set list of features or improving the game and once we finished with those tasks, hand the updated prototype to the other person to work on the next set of tasks, repeating the process until we finished implementing everything we needed to. This ensured that changes we made to the prototype would carry over once another person worked on the prototype, ensuring no progress was lost and we were contributing equally to the prototype. From this, I’ve learnt that even with the limitations set upon us by the tools we were given, by communicating with each other and having a clear understanding on what needs to be done, you can come up with a solution to get past those limitations.

The most important thing I’ve learnt however, is that playtesting is valuable and is as crucial as any other part of the game development process. As the original creator of Hyperblast, it’s hard for me to see what exactly works to make the game fun and what doesn’t as I know how the game works inside and out. The same applies to my teammates as they had worked on the game as well, giving them a deeper understanding of how the game works which a player wouldn’t have. We needed to know however, if the core mechanics of Hyperblast (movement and combat) worked and were fun from the persepctive of a player which is where the external playtesters came in. From our playtesting sessions, we were able to gather a lot of data on whether the core of the game was fun. We found issues such as players preferring to use one type of ship and weapon over the other options which made the whole concept of customising your ship sort off futile. In the end, we concluded that the problem did not have to do with how the core mechanics worked, but instead with the systems built around them such as ammo. We got to work iterating on the prototype and from there we were able to improve our Hyperblast prototype. Before this assignment, I felt that playtesting my own game would be enough to figure out what made it fun and what didn’t but now I realise that working so closely on the game skews how you view it and in turn what you think works for the game versus what actually works for the game.

There is a lot more I have learnt about the prototyping and playtesting process from this assignment however, I feel I have discussed quite the main points in this blog post. This is only the beginning however, as the prototyping and playtesting we did was very simple and due to how little our sample size for data was (we were only required to playtest with five people, we did six), the assignment was more so introducing us to the process. Overall, I’m very happy with how this assignment went, we achieved what we set out to with our prototype and we were able to get consistent findings on what we wanted to test for our game. To end off this post, here is a video showing the main features of our final prototype. 

 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,

Its currently 5:00 pm on a Thursday afternoon and our team has just wrapped up on our first few playtesting sessions. For the most part, the process has gone pretty smoothly and we are already getting good data on what needs to be improved for our final version of the prototype. 

As I discussed in my previous post, each of our team mates had a different role to play while playtesting. Josh would facilitate playtesting, Felix would note down events and actions the play-tester does while playing the game and I would note down any comments they make as well as any other observations I make as they play. To facilitate this, we made five documents that would help in this process: a playtesting script, a pre-game questionnaire, a post-game questionnaire, a document to note down player events/actions and a document to note down player comments/observations.

Screenshot of part of our playtesting script. In it, we have written down what we have to say to the play-tester to introduce them to the game and the playtesting process and prompts to get them to talk as they play.

Screenshot of part of our pre-game questionnaire designed to get some demographic data on those who play tested our game so we can get a good idea on why they play the game the way they do and comments they make.

Screenshot of part of our post-game questionnaire designed to get data on what play-testers thought about the game’s different elements and as a whole.

Screenshot of part of our Comments document. In it, we have written down any comments the player made while also noting down any observations we made as they played.

Screenshot of part of our Events/Actions document. In it, we have written down the events the play-tester did as they played the game.

With these documents, we were able to smoothly conduct playtests and gather the data we needed. While we haven’t thoroughly analysed the survey data, from the notes we have taken down during playtesting and discussion amongst our team , we have already started to find the main issues with our prototype we need to improve:

Playtesters frequently did not notice when they entered a new wave or that they got a power up or even what the power up did. 

Playtesters were not aware that weapons had an ammo capacity and got confused when they started firing slower

Both of these problems, as well as some other minor issues, were attributed to the fact that play testers commented that with so much going on in the game, they did not pay much attention to the UI on the sides of the screen.

The button ‘Inititate Hyperblast’ on the customisation screen due to the way it was designed does not instantly take the player to the game screen, instead starting a three second countdown before doing so. Players would continuously press the button thinking it didn’t work, resetting the timer and causing them to think they broke the game or the game was taking its time to load.

The font used made it hard to read large blocks of text in the help screen and Qs looked more like Os, making it confusing to read.

Most of these issues relate to the UI of our game. This was something I sort of expected as this is an area of development where our development team is not particularly experienced with in GDevelop. These issues for the most part have easy solutions for them and I’m confident that our team can come up with something to tackle the more difficult issues found. A positive from all this however, is that none of the issues were really targeted towards the core mechanics of movement and combat. The general consensus from playtesters was that while the core mechanics were a bit strange and challenging at first, they adapted to it quickly as they kept playing. 

We plan to get more playtesting done next week in order to consolidate what are the most important issues for us to solve in our prototype but overall, I feel we are in a good place in terms of what we have gathered from playtesting.

Hi Everyone,

It’s currently just past midway through the semester break and the Hyperblast Dev Team have been hard at work developing and prototyping Hyperblast. In general, development has gone surprisingly smoothly and we have almost completed all the features we set out to implement with the only thing left to do is some minor tweaks and bug fixes. I think the main reason for why work has gone so smoothly is our team’s clear communication and workflow that we established early on.

After handing in Part A of our assignment which detailed our game, team roles and development timeline, I got to work preparing my original workshop prototype for group development. Most of that just involved reorganising and commenting my code so that it would be easier for my team members to go through and understand it. This turned out to be a good idea as I found that a lot of my code could be refined and grouped up to make sorting through the generally messy GDevelop code easier.

Snippet of Code Groups from the Hyperblast Project

Once I had uploaded it for the rest of the group to work on, we ran into a bit of a problem. GDevelop doesn’t have a version control system in place or a cloud-based system where all of us could work on the game at once, meaning changes we made on our computers to the project would not carry over to other team member’s version of the project. Having only a good week to implement all the features we wanted in the game before playtesting began, it was important to us that we established how exactly we would work on the game to maximise our development time.

We discussed many ways that we as team could efficiently work on the game. We first discussed simultaneously working on the same version of the project but on different tasks and then combining all the changes at the end of our development sprint however, we were concerned that doing so would result in a lot of bugs and issues if the same pieces of code were modified differently amongst team members. We then discussed the possibility of having one person work on the main project while the others prototyped individual features which would then be implemented into the main project as the got approved. While this seemed promising, this didn’t seem efficient as we would just have to redo all the work we did within the main project. 

We finally decided on all waterfall-scrum hybrid style workflow. With this workflow, each team member would work on implementing some of their assigned tasks into the main project based off their priority. We then as a group would check if we all agree with the new implementations in the project and once we do, the project would then be handed off to the next person to work on their tasks. The process would then repeat until all tasks were completed for the game. While that person would be iterating on the prototype, the other two would be playtesting the current version of the prototype and reporting any bugs that they found so that those issues could be fixed in the next iteration if it was important enough (e.g. game-breaking bugs and major issues). To keep track of changes made to the project, we also saved different versions of the project and kept a document tracking all the changes made to the project over time.

Different versions of the prototype within a shared cloud drive

Snippet of the Development Log that records changes made to the game in each version

In practice this methodology turned out to work well. One of our team members was unable to work on the game from home due to issues with GDevelop however, this was not too much of an issue as they would focus on preparing the playtesting materials for next week as well as providing feedback on each iteration of the prototype. My other team member and I would alternate between each other developing the prototype, completing our tasks for the game as well as fixing any issues that occurred during internal playtesting and development. The result of this workflow has lead us to have a ‘feature-complete’ prototype with only minor tweaks needing to be made. Here is the result:

Hi Everyone,

It’s been a few weeks since my last post and it’s been pretty busy since then. I’ve started work on the third assignment for IGB220 which has us form groups of three to four to develop and playtest one of our ideas that we developed during the second assignment, which for me was Hyperblast.

Hyperblast One Sheet

Hyperblast One Page

During our Workshop in Week 9 we were able to showcase what we developed in Assignment 2 if we wished to further develop our prototype to see if there was anyone else interested in developing our ideas. As I felt that Hyperblast as a game was very expandable as well as having a unique and fun mechanic, I decided to pitch my game to see if anyone else would like to work on it. Unfortunately I found that not many people were interested in Hyperblast. In my opinion, I feel this is due to me not doing a good enough job of pitching the game as well as the artwork of the one sheet not really standing out, as I noticed the games that had more complex/ aesthetically-pleasing artwork were the ones that people wanted to work on. My direction for Hyperblast was very much design-oriented and utilised a very simplistic art style as I feel doing so allows the design goals I have to be achievable within the scope of development we have.

I did find one person who was interested in developing Hyperblast, which was Felix. He had a very similar game to me both thematically and element-wise. We got to work discussing ideas for expanding Hyperblast, using the one page as our guide and how we could go about implementing them in GDevelop. Our group expanded the following week however, as another person in our workshop, Josh, was away the previous week and was unable to join a group.

With our final group formed, we started to assign roles.  Josh had previous experience with playtesting as he had done it during previous units he had done so he would be in charge of facilitating playtesting. As the original developer for Hyperblast, I would be the lead designer for development and during playtesting, be in charge of taking notes on comments playtesters make while playing the game. Felix during playtesting would be in charge of taking notes on actions/events that playtesters do while playing the game. All of three of us would have the role of programmer with each of us contributing some form of development to the actual game.

We also discussed what exactly it was that we wanted to test and get data on from our playtesting. We all agreed that the core mechanics of movement and combat were integral to how much fun and enjoyment the player got out of playing Hyperblast, so we decided that would be our focus during playtesting. With a clear idea on how we would approach development and playtesting, we drafted up a prototyping and playtesting timeline.

The first two weeks would be focused on getting the majority of our planned features implemented into the prototype and preparing our playtesting materials. After those two weeks our focus will shift to getting playtesting data and iterating upon the prototype from that. In the final two weeks, we then planned on finalising the prototype as well as our playtesting findings.

There is a lot to develop here and not a lot of time but I’m confident we should be able to get it done. All of us have made some pretty cool games in the previous prototype development cycles and with the combined experience we have from making them, it shouldn’t be too difficult to achieve what we set out to make.

Hi Everyone,

In my last post I talked about the one page I had designed for Hyperblast and said I would cover the one sheet in my next post. I found the one sheet to be pretty fun to design and am pretty happy overall with how it turned out.

The one sheet is a document that is supposed to pitch the game to get others on board with developing the game in some capacity, briefly going over what the game is and will be about, what makes the game unique and have some sort of artwork to represent the gameplay. I condensed a lot of what I had on my one page into my one sheet which made the writing portions for the one sheet pretty easy however, I struggled a lot with how I would represent the game through some artwork. Just like the one page, the one sheet went through many iterations:

First iteration

Second Iteration

Third Iteration

Fourth Iteration

Fifth and Final Iteration

There were five main iterations of the one sheet (15 in total including all the experimental ones I did to nail the aesthetic of the one sheet). In the first and second iteration I decided to focus on just listing the information required for the one sheet and worry about the artwork later. I then added artwork in the third iteration but there was something wrong with it. The artwork did not convey what the gameplay of Hyperblast was in any way. Hyperblast’s gameplay can be broken down to two simple things: weaving between and shooting enemies. As it currently stood, the third iteration just had a bunch of triangles with no relationship being drawn between them. So, in the fourth iteration, I added the player ship moving between two of the enemy ships and shooting at a third, I also added a fourth ship which was coming out of the hyperblast portal to convey the idea that that was where the enemies were coming from. I was pretty happy with this version, so I decided to refine it a bit further so that the idea of multiple types of enemies were conveyed and also spice up the information text, giving me the fifth and final iteration of the one sheet.

The one sheet was fun to make but I’m not particularly fond of it as something to use as a pitching document. Aesthetically, its much more pleasing than the one page but I think a one page along with accompanying illustrations could also do the trick however, I do understand the convenience of having one simple aesthetically pleasing document, especially if it is supposed to drawn in other stakeholders.

Hi Everyone,

I recently finished my second assignment for IGB220 and thought I should go over how that went since I said in my last post that Hyperblast would be the game I would use for that assignment. In this blog post, I’ll be covering the one page I made for Hyperblast and in the next one I’ll go over my one sheet. To start off, here is the final product:

The one page itself is pretty detailed as you can see. I won’t go into too much detail about the different sections of the one page as you can just read it for yourself but I can give a general overview of each section so you can get the idea of how I plan to expand Hyperblast:

The Player - Goes over the core player mechanics as well as the ability to customise your ship and weapon.

The Bosses - Goes over the different bosses that will be in the game, including how they will function and what skills of the player they will test.

Scoring and High Scores - Goes over how scoring and high scores work in the game.

The Enemies - Goes over the different enemy types in the game, including how many points they are worth, their colour and how they will function.

The Power-Ups - Goes over the different power-ups that will be in the game, including what type of gameplay they will encourage (offensive or evasive).

Gameplay Screen Mockup Illustration - Brings all the sections discussed previously together into one illustration that gives a visual representation of how the game will look and function.

Ship and Weapon Customisation Screen Mockup Illustration - A side illustration which will displays how the ship and weapon customisation screen will look.

Controls Diagram - A diagram which contains the controls for the game.

Getting to this stage was not so easy however as I found what exactly what I wanted to to communicate through this document and how to fit it all into one page pretty difficult. Here is the first iteration:

At first, I just had a mockup of what the game would look like, a description of the game, my contact details and most importantly a list of features of the game. I wasn’t happy with the document however as you can see this is very different from what the final one page ended up looking like. A one page is supposed to be a document that contains enough details about the design of the game that a group of designers and other developers could take it and use it to develop the actual game. In addition to that, the features of the game listed were not every descriptive, leading to me ask the question whenever I added an element to the one page, would a designer be able to take the information I gave them and develop it? After taking this question more into consideration, my one page developed further:

The next iteration added annotations to the gameplay illustration and the control scheme for the game but still I felt there was not enough details that a designer could take this and make a game with it. I had to take a step back and think how could I put all the information I wanted onto the page without it just being an information dump? I was also having trouble finding a way to put this info onto one page and still have it formatted in a coherent way. After a lot of thinking, I decided to break up my game into the main elements that made it up:

The Player 

The Enemies

The Bosses

The Power-Ups

From there, I listed what made up these different elements of the game and was able to modify and add to my one page from there:

The one page was starting to come together. I was able to get feedback from a few people about formatting and my tutor also gave me feedback stating that I should add an image displaying how ship and weapon customisation worked so I added that and that became the final version of the one page:

While I did find it difficult to make the one page, I do find it very useful. It allowed me to put all of my ideas into a format that was concise and easy to read. I feel I did good job on communicating all the features that will make up the game and feel that a designer would be able to pick it up and develop the game. In the future, I think I will use this one pages more to document my ideas for games as I find them to be a very useful design tool.

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,

It’s been a busy week with assignment work ramping up so I’ve been posting less but I thought I’d do an update on how playtesting went for Hyperblast on Tuesday. I made some changes to the prototype in between the last post so before I get into it, here’s a video of the prototype so far:

For the most part, playtesting Hyperblast went pretty well. 

In Chapter 9 of Game Design Workshop, Fullerton (2019) talks about how play testing should be conducted, stating that you should introduce to the tester what your game is about, allow the tester to play your game and think out loud without interfering, and ask them questions about the game after they’ve played it. By doing so, the feedback your play tester provides is less likely to be swayed or influenced by what you say. In previous play testing sessions, I’ve been pretty lax with the process, often talking about the game with the tester and answering their questions, but I realise that doing so may mean I’m not getting accurate or even the right feedback as what I say may sway what they think of the game. Getting the play testing right this time was especially important for me, as I plan on using Hyperblast for my second IGB220 assignment, so I needed to ensure that the core gameplay mechanic of the side-to-side movement was fun and intuitive.

I applied what I read from Chapter 9 of Game Design Workshop when conducting playtesting for Hyperblast. I would give the tester some background information on the game, let them play it and just take notes on what they say and observations I made on how they played and then asked them about the game afterwards. I wasn’t able to conduct many in-person play-testing sessions due to COVID-19 but the process for those playtesting online was very similar: I uploaded a copy of my Hyperblast elevator pitch for testers to read, they then could play the game and then afterwards write their feedback in a Google doc I provided (this probably worked to my advantage as I wouldn’t have any way of interfering as they played the game). This playtesting process turned out to work well as after I collated my notes, I was able to hone down to a few key points for where my prototype did well and where it could improve.

Positives

The core mechanic of the side to side movement made the game more fun and challenging as you would always have to be on the move

The art, sound effects and gameplay were very polished for a prototype

What Could Be Improved

Enemy projectiles were very hard to see, causing players to get hit by them unexpectedly

While the gameplay was fun enough for multiple playthroughs, there wasn’t much sense of of progression and the game started to feel repetitive after a while.

From this feedback, I was able to see that the core mechanic of Hyperblast worked well and made the game fun, so I’m confident that I’ll be able to develop this prototype further. Aside from the minor issue regarding the enemy projectiles, the main issue was that testers did not feel they were making any progress, but after taking some time reflecting on why that’s the case, I think this has to do more with the fact I spent more time focusing on getting the core mechanics right rather than padding out the prototype with content that would give the player that sense of progression; quality over quantity. Overall, I feel confident with where I could take Hyperblast and that I am able to conduct playtests properly.

Thanks for reading!

References:

Hi Everyone,

Back in the second lecture of this unit, we discussed that you can never really predict how players will experience your game. You can’t make the player have fun while playing your game nor can you intentionally design there to be fun. In Chapter 2 of Game Design Workshop, Fullerton (2019) compares games to car engines in this way, stating that just as you cannot see how the different parts of an engine work together until you turn it on, you cannot understand how the player will perceive the different elements of your game until they actually play it. Linking back to what was discussed in the lecture, games should then be developed iteratively, with each iteration trying to find what works for the game and what slows it down. To summarise, you have to ‘follow the fun’ when developing your game. While I feel that I have been designing iteratively in previous development cycles, I feel that my purpose for doing so wasn’t to follow the fun, but instead trying to work with the limitations of GDevelop in order to create my original vision for my prototype, sometimes being too rigid in wanting to fulfil what I set out to create. This was very apparent during playtesting, as those who played my prototypes would comment on how refined and polished the gameplay was but not really how fun it was. Now that I am more experienced with GDevelop after about a month of learning to use it, I decided to focus instead on ‘finding the fun’ in my next prototype, Hyperblast (I initially called it Hyperdrive, but after a google search, I changed it to Hyperblast as I want to use it for my next assignment).

If you’ve read my previous post about my elevator pitch for Hyperblast, you’ll know what the game is about but for those who haven’t, the gist of it is dodging enemies and firing at them in order to get to the head of an alien invasion. In my head, the player would have full control over their movement, in that if they press a or d they will move in the respective direction and they’ll stop if no keys are pressed. While playtesting my prototype, I found the gameplay to be bland as the player could sometimes go without moving for long periods by just staying in the same lane and shooting the enemies that would come in front of them. I found that my original vision for how Hyperblast would be played was not as fun as I had hoped it’d be.

It took me a while to come up with a solution for how I could make movement and combat (the core gameplay) more engaging. Knowing the limits of GDevelop, I knew trying to create more complex enemy AI would most likely be a waste of time. I then remembered in our week 5 lecture, that we discussed that limitations can make gameplay more fun. Applying that to Hyperblast, I made it so that the player had limited control over movement. If they pressed a, they would continue to move left until they pressed d and vice-versa. The effects of this slight tweak to the rules of the game made it so that the player must always actively be moving in order to dodge and shoot enemies, fulfilling the vision of how I thought the game should be played. I designed the rest of the elements of my game around this limitation and after a few hours of work, here is the result:

I still feel the prototype could use some work (but in all honesty, when don’t they) but what matters is the core gameplay is there and it feels fun (at least to me). To wrap up, another thing discussed in the week 2 lecture is that games should be designed playfully. I’ve learned now that sometimes I can get too focused on creating a specific vision I have for a game that I forget to look for what actually makes it fun and follow it.  Perhaps with this prototype, I will take more time to just experiment and see if anything fun emerges from that.

Thanks for reading! References:

Hi Everyone,

Today I started the next development sprint, with this sprint’s game being inspired by endless runner games such as Temple Run and Subway Surfers. The idea I ended up coming up with is called Hyperdrive and I might actually use this prototype for my one-sheet and one-page assignment.

Elevator Pitch

Title of Game: Hyperdrive

Genre(s): Endless Runner, Shoot ‘Em Up, Arcade

Elevator Pitch

Hyperdrive is a bullet-hell endless runner where you are in control of a ship trying to fight your way and find the head of an alien invasion in order to eliminate them. You must dodge and weave your way through debris and enemy fire, and use an assortment of weapons to get past unavoidable obstacles and the bosses you face as you make your way to the mastermind behind it all.

Image

Setting/Style

Hyperblast will be a space-themed game, taking place in the midst of an alien invasion of Earth.

Control Diagram

A and D to strafe left and right

Space to shoot

R to restart

3 Unique Selling Points

Fast-paced bullet hell gameplay mixed with endless runner giving it a good amount of replayability

A small but diverse array of enemies (inspired by Doom) that allow players to employ a variety of tactics and tools to combat them

Bosses at score milestones gives players something to strive for in the endless runner aside from just the score

Target Audience

The target audience of Hyperblast will be people who enjoy classic arcade shoot ‘em ups such as Space Invaders and Galaga.

Student Contact Info

Name: Mark Auman

Student Number: n10752340

 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.

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: