becsgamedev

[becsgamedev]

Assignment 3 Postmortem

The goal of this assignment was to design a game based on one of our group members prototype to learn about how to work in a group and the processes of playtesting and building a game. It was interesting seeing how we all collaborated as a group and the different levels of game design knowlegdge that was applied throughout the process of this assignment.

Overall I think Connor and I worked really well together, he understands the code system more than I do and helped me in areas of that where as I am more design focused and helped give feedback and design choices for whatever Connor and I were working on. The other two I didn't work as well with due to their lack of commitment to the assignment but still helped them along in getting a playable game in the end.

Overall it was a fun experience creating a game with others and being able to be apart of a game development process and explore concepts of playtesting.

[becsgamedev]

Assignment 3 Playtesting

In total we had 5 people playtest our game, with great feedback and critisism we were able to implement changes every week based on an outside opinion and not our own. It was pretty cool to experience a proper playtest on our game, it gave us more motivation to keep working on it as a team and give us direction on what to add / any changes we needed to make.

Here is an example of some playtest notes that I had written for our third playtest week.

[becsgamedev]

Assignment 3 Development Progress

For assignment 3 I joined a group with Connor, Callum, and Kymani, we all decided my game was the strongest to develop out of the three. For the playtesting Connor was the questionaire role, Kymani and Callum were the note takers, and my roles was the script / notetaker for parts. I first started by giving my group my first version of my game that didn't have a whole lot of progress in terms of levels. We decided one level per person was a fair amount of work to distribute between each group memeber while also helping eachother where we could. I created the first level of the game alongside all of the menu screens in the game. Throughout the process of building this game there were some time managment issues with some team members in the group, alongside minor issues with the learning curve of GDevelop and the degree of learning each member did. Besides our issues we created a fun game that is playable.

[becsgamedev]

Assignment 2 Progress

I decided to progress my platformer game for my assignment 2 as I enjoyed making it the most out of the three and thought I had the best design out of all the prototypes I made.

This is my one sheet, one-page designs I created for Desolate Ruins.

[becsgamedev]

Racing Postmortem

The purpose of this prototype was to learn and explore another type of game that isn't a platformer or an asteroids game. Personally this was the most challenging out of the prototypes as I never really put much thought into how these type of games were made and only ever played games such as Temple Run or Subway surfers when I was little.

I struggled more on the fact of making this game more than just "dodge the obstacles and collect coins", having an infinite level that speeds up felt like I didn't have much room to improve the base mechanics or make it unique to the genre of game that already exists.

If I were to change anything about the game I would spend a lot more time planning the basics of the game before taking it into GDevelop as seeing a screen with a car and a road felt like it restricted my thought process of what to do with the game. None the less I had a lot of fun experimenting with this style of game

[becsgamedev]

Racing Development Post (DriveRun)

I firsted created the layout of the game with the templates we were given in the workshop, I then added a few obstacles for the player to dodge and set up the movement for the car. I spent most of my time working on the code for the player to dodge the obstacles and collecting coins rather than the UI showing the amount of coins or how many times the player had been slowed down. I still need to brainstorm some ideas to make the gameplay more interesting and make the level infinite with random spawning obstacles.

Issues:

No UI

Gameplay seems boring

The coins need to be for something (or add scoring system)

Enemies? or some other obstacle that applies pressure on the player.

I would like to further implement most if not all of those points into the prototype to create a more interesting game and add aspects of replayability.

Here is the game in its first version:

For my readings this week I decided to focus on chapter 10 of Fullerton's game design workshop book where she talks about the functionality, completeness, and balace of a game. I related my game to the section of foundation the most as I had issues of my game currently feeling boring. I used this chapter to brainstorm more ideas of what could make this game more fun (visual aspects, obstacles, playability).

Source:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[becsgamedev]

Racing Elevator Pitch (Drive Run)

For my final IGB120 prototype I will be creating a top-down drive movement game.

Drive Run is a top down driving game where the player has to dodge and weave through obstacles and collect coins. As the player runs into obstacles they slow down, if they slow down too much the level will catch them and the player will lose. This simple yet fun design has been seen in many other games such as Temple run, and Subway Surfers, in which are my inspiration for my design.

This prototypes audience is for all ages as well as those who enjoy racing games. The main focus of this game is mechanic based as the level is infinite but needs to be sped up to create an enjoyable replayable game.

Here are some inspiration images from similar games:

Source:

Bernstein, M. (2020, November 10). Critical Play: Temple Run and Tiny Wings. Medium. https://mattkber.medium.com/critical-play-temple-run-and-tiny-wings-7a84479734ba

‌

Source:

Knezovic, A. (2024, March 1). Subway Surfers: Lessons from the Record-Breaking Mobile Game. Udonis. https://medium.com/udonis/subway-surfers-lessons-from-the-record-breaking-mobile-game-8a0d26635945

‌Once again I considered theory from previous workshops about how to create a solid elevator pitch.

[becsgamedev]

Asteroids Postmortem

The purpose of this prototype was to explore a different type of game and mechanics that differ from the platformer style in GDevelop. Personally this was a bigger learning curve as it required different mechanics and code to make the enemies work. Even though I didn't put a whole lot of time into this prototype I do believe I learnt a lot about the theory of trying to create unique gameplay with a genre of game that is so well known and that has been recreated thousands of times.

If I were to change any processes I would keep to my previous post of time management, alongside spending more time learning GDevelop's coding system. Although it appears simple, I am only used to language based code such as C#, so it felt weird to try code in a more simplified version as I couldn't create seperate scripts for all my objects.

As for my prototype I would've loved to add more interesting visual elements and enemies which would've made the game feel more fun to play and unique to the style of classic asteroids.

[becsgamedev]

Asteroids Development Post

As I focused most of my attention on other prototypes I didn't get to develeop this project as far as I intended and only implemented basic mechanics such as score, enemy death, and damage.

I first created the basic scoring system and the objective that the player had to project the research station in the middle. Enemies and debri's spawn from the outside that all head toward the centre in which the player must destory otherwise the research station would break and the player would lose.

Issues:

No health mechanic

Needs more interesting gameplay

Needs more enemies

Upgrades and powerups

All of these issues should be addressed and implemented before the playtest of this prototype.

For this week I read chapter 5 of Fullerton's game design workshop to help me think about the processes of behaviours of objects to get an understanding of the impact they have to a game. "The more potential behaviours as object has, the less predictable its actions within the system." After doing my readings I started brainstorming ideas for different potential enemy behaviours that can make my game feel more unique and unpredictable.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[becsgamedev]

Asteroids Elevator Pitch (AstroGuard)

For my second IGB120 prototype I will be creating a 2D, asteroids game in the style of a roguelike.

AstroGuard is a standard asteroids game where the player plays as a guard and must protect the research station from any enemies trying to destroy it. With this fast pased gameplay and wave based enemies the player must learn to be efficient and not crumble under pressure. For every wave the player completes they will be rewarded with an upgrade that can help them protect the research station.

This prototypes target audience include those of all ages, there will be no violent graphics, and will mainly focus on core gameplay mechanics. The style of the prototype is very much a classic arcarde asteroids game following with the same type of movement and damage found in most asteroid games.

Here are some inspiration images from similar games:

Source:

Asteroids (Atari 7800) - online game | RetroGames.cz. (n.d.). Www.retrogames.cz. https://www.retrogames.cz/play_125-Atari7800.php

‌Source:

Dormehl, L. (2014, March 11). Super Asteroid Attack Is Everything You Love About Classic Arcade Games [Review]. Cult of Mac. https://www.cultofmac.com/269444/super-asteroid-attack-represents-everything-love-classic-arcade-games-review/

‌I considered the theory from the previous elevator pitch about what to include and how much information should or shouldn't be included, I tried keeping it simple and interesting.

[becsgamedev]

Platformer Postmortem

The purpose of this prototype was to create a working platformer in the program GDevelop that can be seen as a learning curve for both game design and aspects of playtesting. Although most of my time was put into design rather than unique gameplay, I do believe I've learnt a lot from creating this and have enjoyed to challenges of video game design even if I didn't particually enjoy using the progrm.

If I were to change any processss I went through I would start with my time management by creating lists based on what tasks are more important to get done early on in the game. I dove straight into design as that's what I'm most interested in but it caused issues that were harder to solve in the long run, as well as setting a standard on what I should be doing first as industry game development never starts with the design over mechanics. In the game deisgn workshop written by Fullerton, it is mentioned that playtesting and prototyping is very important in the design process and allows for mass feedback without putting a lot of hard work into the art or mechanics first.

As for my prototype if I had more time I would've loved to implement more attacks and a unique aspect of gameplay such as mana or stamina. This would allow for the game to be played differently rather than just attacking the skeletons as you progressed through the level.

Sources:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[becsgamedev]

Platformer Playtesting

Before I allowed for any playtesting on my prototype I focused on fixing the main issues and implementing some mechanical aspects so the playtester had functions to explore and an objective for the level.

These mechanics include player health, player damage, skeleton health, skeleton damage, and overall fixing the collision points and animations of both the player and the enemy.

This is short clip of the first part of the level in action:

The overall feedback from this was mostly positive, with only minor critiques that I should focus on fixing.

These include:

Changing the keybinds to more common keys

Making the player health stand out more

Making the NPC give the player information on how to play

Scaling the skeleons so they are bigger

This playtest was helpful in making me understand general housekeeping of the level, for example, although the controls made sense to me it may not be as obvious to other people. Seeing my design in the eyes of another player allowed me to change small things that have a bigger impact on the game, such as the player health bar and skeleton scaling.

[becsgamedev]

GDevelop Experimentation

As I have been experimenting with GDevelop I have implemented a few changes that differ from the basic Gdev platformer that we were guided to create, although I kept the same amount of simplicity but just added a few sprites.

Firstly I added new sprites and assets to make the game more unique looking, I watched a few basic YouTube tutorials that helped me learn how collision, movement, and animation worked. This gave me a great undertstanding on the basics even though no real mechanics were added yet. I had a lot of fun layering the sprites and creating a base level that looked really cool.

There are a few glitches I have yet to figure out yet such as the player being lower than the platforms, the player health just being static, and the player animations being janky, which I intend to fix before the playtest of this platform prototype.

Sources:

GDevelop. (2022, June 3). Sprite Object - In Depth Tutorial - GDevelop. YouTube. https://www.youtube.com/watch?v=2eOhvUIL4vg

‌

[becsgamedev]

Development Post #1

As this is my first time using GDevelop I focused my first weeks progress on learning the events system and experimenting with different sprites before starting to develop the early stages of my game. (This is also my first experience with pixel art).

I first created my own sprites to see how difficult / time consuming it would be verses using free sprite assets online, I found out creating your own sprites isn't as easy as it seems and can cause future problems. I set up a player controller, camera movement, and player attack to get the basic mechanics down.

My first attempt:

Issues:

Sprites didn't match their frame size

Time consuming to make

Wasn't happy with the design

Although drawing my own sprites was fun and their collision boxes worked fine when the game was ran, I couldn't quite figure out why they didn't match their size or how to fix it. My solution to this was sourcing free sprites online to create my game, this allows for more time spent on the core mechanics of the game without having these issues (these will be shown in future posts).

Readings:

For the first week I read chapters 1 & 2 of The Game Design Workshop written by Tracey Fullerton. Throughout the readings Fullerton talks about the iterative process diagram and processes that game designers must go through before developing a game. The core focus must be the gameplay & mechanics before designing the graphics as the player must be engaged and interested before caring about the design. Although Fullerton recommends getting the core fundamentals down before designing the art I decided for my workflow I wanted to get the basic style down first to help progression.

In my platformer I used the same iterative process diagram (1.8 page 17) Fullerton talks about to test out the early stages of sprite creation, this included (generating ideas > testing ideas > evaluating results), as I knew the events system was simple enough to create a player movement and attack system without issues / failure. In the future I would like to experiment with throwing mechanics, dashes, and double jumps to make the gameplay more engaging and fun.

Sources: Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[becsgamedev]

Elevator Pitch

For my first IGB120 prototype I will be making is a 2D, roguelike- platformer.

This game prototype is a Dead Cells meets Hollow Knight inspired platformer in the form of a roguelike. The player is sent on a journey through a scarce, deserted world, taken over by a skeleton army. The player must defeat enemies to upgrade their weaponry as they go, this includes special swords and daggers. Players can take advantage of various mechanics that include dashes, double jumps, throwing mechanics, melee attacks, and fast paced movement as they progress through the game.

This prototypes target audience will be designed for players of all ages who enjoy roguelike games, the combat will not include any gore or heavy violence, and will mainly focus on the visuals and simple combat that make this game fun and visually pleasing.

Here are some inspiration images from similar games:

Dead Cells:

Source: https://www.gog.com/en/game/dead_cells

Hollow Knight:

Source: https://www.pinterest.com.au/pin/hollow-knight-on-the-nintendo-switch-brings-a-dark-soulsesque-twist-to-an-oldschool-platformer-the-game-of-nerds--812055376534091506/

The first lecture had a variety of questions to consider while creating an elevator pitch and a concept for a game in which I had to plan out. In the next post I will be showing my first experiences with the program GDevelop alongside sharing what I learnt from my readings.

[becsgamedev]

About Me :)

Hi I'm Bec! I'm a student at QUT currently studying a Bachelor of Digital and Interactive Games!

My interest in game development started from a very young age, my first ever PC games were Unreal Tournament 3, and Age of Empires III, ever since I have been in love with the process and creation of video games.

My interests and skills mainly focus on the creation of video game environments and exploring different art styles to design new experiences for players. I am interested in and have a fair amount of experience with 3D modelling, 3D sculpting, drawing, and using Unity & Blender.

My goals and objectives for this unit are to expand my knowledge on game development and push myself to create higher quality assets and environments for my portfolio.