MPDev

Firstly, it is important to discuss how unlike the previous prototypes, this one was developed with a team which consisted of 4 members (Including me), so my approach to this prototype was very different compared to when it was just me working on a prototype.

What aspects of the readings helped inspire your design process?

When working on this team project, I found that for me personally, that Chapters 8 and 10 helped my process more than any other chapters.

Chapter 8, as discussed in previous posts, focuses heavily on playtesting games digitally. While Playtests were not an extensive focus for the whole team, I found that it was important to make sure the game was built in increments and having each increment tested, even if only by other team members until we had an opportunity for a much larger playtest with a wider variety of players (Playtest Party).

Chapter 10, which I have also previously discussed, focuses on functionality, completeness, and balance of games.

This chapter also inspired me to work on developing each feature in steps to ensure they each were functional, felt complete, and were balanced. For example, I played around with the box creation system a lot as I had several parts of it that needed to be developed for it to be called functional, including it being a projectile against enemies, only damaging them when it is in the air rather than on the floor, limiting how many you could place, and indicating the age of blocks by changing their color as more spawned to show which ones will break first when the limit is reached.

What’s one thing you’d change about how you developed the prototype?

Overall, I had issues with communication with several team members, causing a very slow process of development, or team members overlapping content and thus lots of confusion ensued. The thing I would most want to change if I could, I would go back and line out a much clearer list of each teams role and tasks, as alot of the workload was put more on myself and one particular teammate rather than it being a fair balance of work, thus leading us to having a much smaller prototype than intended.

What’s one thing you’d change about the design of the prototype?

The main thing I would change would be a lot of the visuals, moreso adding more visuals and making the environment of the level feel more varied. In my mind, this would include more types of platforms, a more detailed version of the players block so it looks more unique compared to the level, more alternate sprites for the robots, a background for the scene, and a visual representation of player lives rather than just text.

Reference:

Game: Builders VS Bots

Team: 21

For Assignment 3, we were required to conduct playtesting in order to find out what did and didn't work within out game. My team has been developing the game 'Builders VS Bots' and our primary goal for the playtest was to determine how well the overall features of the game worked in correlation with the rest of the game as well as on their own.

Overall I had gotten 5 different people who were completely naive to what our game was to playtest our game and give us fresh and unbiased feedback on the game.

My teams playtesting was conducted during week 13 during the playtesting party, unfortunately, I was the only member of the team to attend this event and thus had to conduct all playtesting on my own.

Process:

For this playtest, our overall method for testing was to provide the tester with the game, provide them with a pre-scripted intro to what we were doing, and then proceeding to record what they were doing throughout the playtest. Then, once they had completed their playthrough, providing the playtester's with a survey in the form of a google form in order to gain more direct feedback rather than relying on just notes taken during test and discussion with the testers, as with conducting the whole process on my own, this made collecting data more controlled for me as the sole developer collecting it.

Results:

Results from these tests come in two different forms, firstly, find my raw notes taken during test below.

Players all had a positive reaction to creating blocks. Players seemed to have fun throwing them around and discovering new ways they can use them.

Players often took a while to realize features of the blocks including the color indicators showing how old blocks were and that blocks could destroy robots.

Players seemed to have fun overcoming obstacles, but found that resetting back to the beginning of the level felt extremely punishing and annoying.

Players felt that the game needed a background as the world looked a little too simple.

Some bugs were found that we were unaware of. This includes that sometimes when jumping on blocks in weird angles that they all squish down into one another, and some hitboxes were a bit off and led to players taking damage even when not touching obstacles at times.

And the rest of the data collected came in the form of the Google Form Results. Below is a spreadsheet where they have been compiled together.

Survey Results

Overall, from all the data and feedback collected from the playtest, the most common things we learnt from our testers were:

Players loved the idea/concept of the game.

The idea of throwing boxes to platform was generally enjoyed by all testers.

Players found game easy to pick up and play as it had very simplistic controls.

There were several bugs found with the boxes, including weird springy effects when jumped on weirdly.

Overall players disliked the restart from beginning effect when losing lives.

Players loved the open-ended design to levels allowing them to complete it in a number of ways.

Players felt there potentially should be more options for block creation, other than just one singular type of block.

Hit-Boxes were not ideal and made some deaths feel unjust.

Introduction Script:

“Hello and thank you for coming to playtest our game. Before you start, I would like to run you through what we need for this playtest. So what we will have you do is play through the game from start to finish, then we shall provide you with a google form survey for you to fill out in order to gain recordable feedback from you. Lastly before you start, we would like to record footage of the gameplay so that if you identify anything within the playtest, we can look back at your answers and find what you have pointed out, is this ok? (Wait for tester to consent), Ok thank you, now once you are ready, please begin playing through the game”

Playtesting Footage:

Playtester (Daniel)

Playtester (Fred)

Playtester (Jamie)

Playtester (Matilda)

Playtester (Michael)

Sell Sheet:

One Page Design Document:

Team 21:

Name: My Tea Morphin Power Strangers

Members:

Max Powell: n11239093

Andrew Giblin: n11284633

Abhishan Saini: n11274051

Emma Della: n11215712

Project Details:

Title: Builder vs Bots

Genre: Platformer, Action, Adventure

What have we aimed to achieve?

Once our team had decided to continue development for 'Builder vs Bots', our first priority was to make sure the primary mechanics were fully functional. We did this by working together to finalize and determine features such as creating and throwing blocks, destroying robots with them, and using blocks to platform.

What is something I've learnt?

While working on this project with a team, I have improved my understanding of the GDevelop physics system, and how the angles and force can be used in conjunction with the physics system to allow a more controlled ability to throw objects.

On top of this, I have also learn about the variable system of GDevelop in much more detail, and learnt about how we can use it to control and apply various abilities to an object.

For example, when we were updating and modifying the block so that it will only destroy robots when it is falling after it has been thrown, and not damage them when it is lying flat on the ground. Using a boolean variable (isFalling), we were able to toggle this boolean on and off based on where it is in the scene, and only when this variable is on will it hurt robots.

Lastly, I also learnt about the GDevelop Particle System, and how I can apply it to specific moments in order to create explosions. For example, I made a particle with 360 degree emissions and high force which makes it a circular explosion, and by linking it to the actions that destroy the robot, we can create the explosion when the robot is destroy, giving it the appearance of the robot blowing up.

Game Showcase:

Above is a showcase of the whole project thus far.

Above is a more focused showcase of the blocks and how the variable system prevent them from dealing damage when they are on solid ground.

What aspects of the readings helped inspire your design process?

Within the readings, I found that Chapter 10 specifically helped my design process for this prototype.

Chapter 10 focuses on functionality, completeness, and balance, however, I primarily focused on the completeness part of the chapter.

This chapter inspired my process by helping me focus on developing my prototype in a way that the game could be played from start to finish. This lead me to developing a scoring system that would allow a player to reach a victory scene once they had achieved a high enough score before reaching the finish line.

What’s one thing you’d change about how you developed the prototype?

When developing this prototype, I focused way to heavily on learning how to create a scoring system, that I didn't dedicate enough time developing other features such as my intended features of having multiple car choices, as I felt I wanted to understand the scene changing and scoring systems found within GDevelop and thus dedicated too much time on them.

Ideally if I could change how I would develop this Prototype, I would divide my time and better plan out all of the intended features so that I can develop them all with equal amounts of time and dedication

What’s one thing you’d change about the design of the prototype?

If there was anything I'd change about the prototypes design, I'd change the overall level design. While I don't dislike how I've visually designed the game, the actual level design is very bare bones to what I would have liked.

If I could change the design, I would focus more on developing the level to better match the aesthetic design I had intended.

Reference:

What have I tried to achieve?:

For this project, my aim was to experiment combining certain aspects of the game, such as variables and collisions, and using them to change scenes, display text on screen, and delete objects.

I wanted to see if I could link objects the player interacts with to a score which will be displayed on screen, allowing players to gain immediate feedback to their actions.

What is something I've learnt?:

In previous projects I hadn't even tried working with scenes or text objects, so a key part on working on this project was learning how these two parts of GDevelop's engine function.

My first goal was working on learning how to convert a string to a visual score. I learnt that by creating an action that changes the text on screen, and changing the text to a bit of code such as "Laps:" + ToString(Car.Variable(Laps)), it would constantly update the text by using the text in quotation marks as a prefix, and applying the value of the string I had created (Laps) as the suffix allowing the text to display the players current score.

In previous projects, I had never looked into or experimented with having multiple scenes within GDevelop, so everything I did with this was new to me. First part I learnt was how to create new scenes, which was as simple as opening the games properties tab and creating a new scene from there. The next thing I learnt was how to change scenes through actions with conditions. I wanted to use this system to create a victory scene that the player could open to once they had a score of 9 (achieved through going through lap lines) as well as colliding with the finish line.

Game Showcase:

Above is a gif showcasing how going through the lap lines increases the players score (Laps)

Above showcases the player reaching the Finish Line and reaching the victory screen

Above shows the car sprite as it was made in photoshop

Above shows the map sprite as it was made in photoshop

Project Details:

Title: Crazy R.C. Racing (C.R.C.R.)

Genre: Kart Racing

Elevator Pitch:

'Crazy R.C. Racing' is a 2D Top Down Racing Game where players get the chance to select one of the various Remote Control Cars and compete in a race around the toy box.

While racing, each car is outfitted with a Crazy Ability that will give you an edge in the race, and help you earn the position of 1st place.

Primary Mechanics:

Top Down Driving

Scoring Per-Lap

Multiple Cars

Each Car has Unique Ability

Setting:

Children's Toybox which has been organized to make a race track

Target Audience:

Once again, age is open to all ages, however the simplistic and exaggerated cartoon style of the games design aims it towards a younger audience, as well as targeting fans of Kart Racing Games (Such as Mario Kart, Crash Team Racing, and Team Sonic Racing).

World Style Reference:

Source: Click Here

What aspects of the readings helped inspire your design process?

Within the readings, I found that much like in my post-mortem, Chapter 2 was a big part of inspiring my design process, however, after continuing through the readings, Chapter 8 was also a big part in inspiring my process.

As discussed previously, Chapter 2 focus's on the structural elements required to build up a game and this inspired me to focus and think about the elements separately and planning them out in order to structure my design.

On top of this, Chapter 8 focuses on the importance of digital prototyping, and how they are important to help developing a game. This chapter inspired me to focus on developing each feature in stages, and then proceeding to create various testable prototypes as each feature is developed in order to determine how well they function before moving to the next stage of development.

What's one thing you'd change about how you developed the prototype?

When developing this prototype, I did not dedicate as much time as I could have, and thus this lead to the prototype to be very under-developed. If I could have changed anything about how I developed this prototype, I would have dedicated more time to developing this playtest so that it could be much further developed than it is.

What's one thing you'd change about the design of the prototype?

While I am happy with the emphasis on the portal system I designed for this prototype, there isn't much emphasis on the setting of space, I feel that with the design, there needs to be more visual assets that would allow for the scene to much more clearly communicate the setting to the player so that the prototype can much better showcase its design.

Reference:

What have I tried to achieve?:

For this, my aim was to experiment with the mechanic of teleporting objects between the two portals, including the portals redirecting the objects by changing their directory.

What is something I've learnt:

The first new thing I have learnt was how to code and manipulate object positions, angles, and force.

Learning these lead me to figuring out how to make objects, when colliding with the portals, changing and setting their position to the Portals Portal.X() & Portal.Y() position leading them to teleport from one portal to the other.

Using angles, I was able to detect the angle of the players ship and then setting the thrown portals angle to the players current Player.Angle() from when they shot out the portal and thus rotating the portal to match the players angle making them look more natural when they travel through the air.

And by using force in conjunction with angles allowed me to make teleported objects and shot out portals move in the direction set angle, this allowed me to make shot out portals shoot in the direction of where the player was looking, and make asteroids move in the direction of the portal they come out of.

Game Showcase:

Above is a GIF of my initial testing of the portal system.

Above is a GIF of me testing the portals in conjunction with the asteroids.

Above is a screenshot of me creating the Player Space Ship in photoshop.

Above is a screenshot of me creating the Green Portal in photoshop.

Project Details:

Title: Blasphemous Black Holes

Genre: Shoot 'em up, Sci-Fi, Action

Elevator Pitch:

'Blasphemous Black Holes' is a simple Asteroids style game where the player takes on the role of a spaceship that can create black hole portals to redirect incoming projectiles and obstacles in order to ensure their ships safety. Using these black holes, the player can teleport around the level, change the trajectories of asteroids, and redirect projectiles from enemies saucers.

Primary Mechanics:

Free-Flying around entire level

Creating Black Holes/Portals

Redirecting Obstacles

Setting:

The Dangerous Asteroid fields in space.

Target Audience:

Game-play is aimed to be simplistic and easy to pick up for all ages, so the target audience is aimed towards people who like games similar to Asteroids, or even the Portal Games.

World Style Reference Images:

Source: Click Here

What aspects of the readings helped inspire your design process?

I found that aspects specifically from Chapter 2 help inspire my design process for my platformer as Chapter 2's heavy focus on the structures of games helped me better understand how I needed to plan out and design my game. Chapter 2 taught me that without all the structural elements of a game building it up, a games systems and designs will just fall apart.

All of this inspired me in planning out the key elements of the games structure (Goals, Procedures, Rules, Resources, Boundaries, and Outcomes) so that I had a clear idea of how this game will play out, even before testing any.

What’s one thing you’d change about how you developed the prototype?

While developing my prototype, I put to much emphasis on developing the specific feature of creating and placing blocks and thus neglected a lot of the other features of the game. If I could change anything about how I developed the prototype, I would like to have fleshed out more features of the game so that the prototype had more flash to its overall presentation.

What’s one thing you’d change about the design of the prototype?

With the overall design of the prototype, there isn't much emphasis on complex platforming and thus is very simplistic in its jumping and platforming, ideally I feel that there would need to be much better level design for the prototype so that you can get a better feel for how the game will intend to be in its finalized form.

Reference:

Chapter 7: Prototyping

Chapter 7 discusses methods of Physically Prototyping your games by constructing physical models, either designed professionally or even just using pens and paper that represent your game ideas and testing it using these models.

According to Fullerton (2018, p. 203) "Prototyping is the creation of a working model of your idea that allows you to test its feasibility and make improvements to it", this statement accurately describes the purpose of creating and testing game ideas using these physical models as representations of the games in order to improve the planning and development phase of game structure, and game rules.

Fullerton (2018, p. 203) also tells us that "Physical prototypes are the easiest type of prototype for most game designers to construct on their own", which helps to prove how vital that this form of prototyping is to the development process.

Chapter 8: Digital Prototyping

Closely related to the last chapter, Chapter 8 discusses the importance as well as methods of creating and testing Digital Prototypes.

Within this chapter, Fullerton (2018, p. 241) states that "if your final game will be released on a digital platform, at some point in the development process, you will need to create a digital prototype of your concept" and that "digital prototype extends that design work into a digital form and allows you to test the essence of your game in its intended format.", this all states that while physical prototypes help test the foundations of your games ideas, a digital prototype helps contextualize and test the functionality of your games in the medium that they are intended for.

In Conclusion

After reading this chapter, I have discovered many more efficient methods for designing, prototyping, and testing my games, and this information will help in the future as these methods will better allow me to test the foundations of my games and better prove if these ideas will work and if they need to be reworked.

Reference

For me, GDevelop is a new program in which I am generally unfamiliar with using, so I had alot to learn about this system.

What have I tried to achieve?:

First and Foremost, I wanted to figure out how to make the core mechanic of my game concept to work, which is about summoning/creating a box in which the player can interact with.

What is something I've learnt:

When working on my project, I have put a heavy emphasis on a physics system in order to make the box creation system seem much more unique and fun to play with.

So in order to do this, I have started to learn about the inbuilt physics system that is contained within GDevelop.

I learnt that, much like most game engine systems, GDevelop physics objects only appear to interact with other physics objects, which puts a few limitations on how I had initially planned to design my system. However, I learnt that the physics system within GDevelop is quite user friendly as well as extremely in-depth with its settings and configurations with each object.

Game Showcase:

This screenshot shows my initial set-up within GDevelop

Above is a gif showcasing my first attempt with understanding the spawning object system aswell as the physics system.

Screenshot showing the characters design creation within Photoshop.

The Elevator Pitch:

'Builder vs Bots' is a simple platformer game where the player must make his way to the evil robot factory fighting a variety of robots along the way so that you can destroy the Robot Prime who is creating an army of robots to conquer the Earth. Using your characters construction skills, you will collect a variety of resources in order to build blocks that you can use to scale walls, traverse platforms, block enemies, and even pick up and throw at targets to aid you in your quest to save the world.

Project Details:

Title: Builder vs Bots

Genre: Platformer, Action, Adventure

Primary Mechanics:

Running and Jumping between Platforms

Building and Throwing Blocks

Thrown blocks can be used as platforms

Destroying Robots with Blocks

Setting: Modern Day Construction Sites (Along the Scaffolding) which have been over-run by evil robots.

Target Audience: No specific age group targeted, however the target audience will focus on players familiar with and/or enjoy Mario-Esk Platformers.

World Style Reference Images:

The idea of the game world would be that it takes place along construction scaffolding in order to match the concept of playing as a construction worker.

Source: https://www.hireach.com.au/scaffold

Source: https://depositphotos.com/27312109/stock-photo-construction-worker-on-a-scaffold.html

Notes and Thoughts Chapter 1+2:

Chapters 1 and 2 of the Game Design Workshop reading material by Tracy Fullerton covers the topics of the role of the game designer as well as the structure of games.

Within chapter 1, we are told that "game designer envisions how a game will work during play" (Fullerton, 2018, p. 3) and that they are responsible for creating the objectives, rules, and procedures of the game. Also within this chapter, it is discussed that the Game Designer is "advocate for the player" and that they must "look at the world of games through the player's eyes" (Fullerton, 2018, p. 3) which leads us to focus on the overall feel of the game and how a player would expect it to feel.

With this in mind, when preparing my game concept, if I came up with functions and objectives for the game, I needed to create a way that they worked together and how they will work together for the player. An example of this is that my pitch presents the idea of creating boxes as your character is a builder, as a game designer, my role is to determine why a player would do this, and how they would do this so that the overall function and feel of this box creation ability works within the game world. For this example, I looked into the why the player would want to create a box, which for me, I felt that the creation of the box would lead into the ability of throwing these boxes, both as a form of projectile, as well as being able to throw them into place which will allow them to jump upon them and traverse the level in more creative ways.

Chapter 2 focus' on the structure of games. Fullerton states within this chapter that while all games have structure, they do not all share the same structure (2018, p. 31), however, despite this, there are elements discussed that generally all games share. As focused on within this chapter, structural elements commonly shared by every game tend to be the inclusion of Objectives/Goals (Overall task that achieving will progress or complete the game), Procedures (Generally what players can do to achieve these objectives/goals), Rules (What players can and can't do), Resources (Can consist of pick-ups to even just scores), Boundaries (Simply special rules that prevent players from doing specific things), and Outcomes (The fruits of the players labors, may simply be winning the game) (Fullerton, 2018, pp. 34-38).

Overall, a game is simply the sum of all its parts, or should we say, the sum of all of its structure, and understanding your own games structure is vital to creating your game. For my own game, the structure was determined with these common structural aspects, with the objective being to reach the exit or beat the boss at the end of the level, the procedures consisting of creating boxes and traversing the level to destroy and avoid enemy's in order to reach the end, the rules being that the players can create boxes and throw them, and that the players cannot physically collide with robots without taking damage, the resources being the materials collected to create the boxes, the boundaries being the physical pitfalls across the level preventing certain paths of travel, and lastly, the outcome simply being victory to the player.

References:

Hello everyone, I'm Max I am currently studying Game Development here at QUT in the hopes to hone my skills in Game Development and Game Design. Throughout this Unit, I aim to improve my understanding of the Game Design process, and gain more skills in the Game Development Process.