IGB220 Postmortem
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.
Thanks for reading!











