smallnim

[smallnim]

Assignment 3 Postmortem

This post is about my assignment 3 game which was a collaborative development with two of my colleagues - Alex and Luke. The game we developed is called 'Swordsage: Oakwood Adventure' and it is a platformer adventure game. Within this post I will be evaluating the development process and explain the design reasonings behind the game respective to my contributions. In addition to this, I will be referencing segments of Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition (Fullerton, 2018) to explain my design reasonings.

Of the three of us who worked on 'Swordsage', I was responsible for level designing. Taking into account that I would be level designing, I had to position myself in the perspective of the players, taking on a playcentric design process and having thoughts such as "what do players generally find engaging in platformers" or "what aspects generally draw players' attention within adventure games". I had to take on these thoughts to draw out ideas that would give players the ideal experience. Through this process, I was able to think of ways to utilise the provided sprites and assets to develop a tutorial level that would give players insight into the possibilities the game had as an adventure platformer. This resulted in the usage of several jump mechanics and traversal techniques, allowing players to challenge themselves by thinking about how they will tackle challenges moving forward in the game. In addition to this, to add more challenge to the game, monsters would be placed appropriately around the map, giving players new obstacles to take on rather than just the platforms.

In addition to this, the game also utilised formal elements, specifically rules, resources, and conflict. These elements were utilised to shape the boundaries and fundamentals of the game. Through having rules such as void boundaries and different interaction outcomes, players would not be limited, but rather led on the right path to explore the game as designed to be, allowing players to experience the game without having conflicting thoughts such as becoming confused or bored as they are guided towards the right path. For resources, the game utilised a health feature, this was developed to give players a value to their health, invoking the need for players to think about how they will handle situations given that they will be reset upon losing all their hearts. In addition to this, to counter-balance the fact that players lose a portion of their health per interaction with monsters, features such as healing statues were implemented to restore the player's health value. As for the conflict elements within the game, players are challenged to progress through a series of platforms at their own pace while taking on monsters along the way.

Now moving forward, I will go on to reflect about the end results of the game's development.

The results of the game came out rather well. People who helped playtest the game were rather happy with its state and gave positive feedback, claiming that the level design was aesthetic, the game was fun, and that the game was easy to get used to. On another note however, there were still feedback that showed discontentment with the game, and in all honesty, that is to be expected and accepted. The current state of the game is incomplete, however, this was due to the inability to find and include more sprites within the game, limiting the development team from improving the overall player experience. In addition to this, GDevelop was also insufficient in the sense that it limited us as developers from being able to run the game smoothly when implementing new features such as special effects to add a more lively feel to the environment.

Overall though, this assignment has contributed majorly to my experience as a game developer in learning as I have learnt multiple things not just from the workshops and the book, but also my colleagues.

Following this section of text will be screenshots and a video demonstrating the current state of the game.

Screenshots of Code:

Screenshot of Level Design:

Video of Gameplay:

(my own recording - was also used for the report document)

Reference:

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

[smallnim]

Assignment 3 - Playtesting

For the 3rd assignment, we are tasked to conduct a playtest with someone who is unfamiliar with the game.

We each decided to get 2 - 3 people each to playtest our prototype game. In this case, I asked two of my friends outside of University to partake in this playtest.

To start off with the playtest, I first introduced them to the game and followed the template script provided on canvas.

After the introduction and playtesting, I followed up with a questionnaire using the provided template on canvas.

Through conducting the questionnaire, it was deduced that the participants were both naive users who claimed to be experienced video gamers who both have over an average of 30 hours or more spent gaming a week. Both of these players were PC players regularly enjoy FPS, RPG, Action, and Fighting games.

With this knowledge in mind, it provided a bit of insight into findings of this playtest.

For the findings of the playtest, I used the provided template on canvas and noted down both the positive and negative findings throughout the playtest. Many of the findings were similar to the results that we as a team had found already when playtesting it ourselves, however, this just further proves that those areas need significant improvement to be up to standard.

Below this will be the screenshots of the respective templates used:

Also note that the templates were mostly untouched aside from a few minor adjustments as the contents did not need to be changed.

Playtest Script:

Playtest Surveys (names and final opinions):

Playtest Questionnaire:

Playtest Findings:

(The playtest findings were combined and put into several screenshots on a shared google docs)

[smallnim]

Assignment 3 - Prototyping

Following the game design documents for assignment 2, assignment 3 requires us to form teams to develop a game based on a one page presented by a team member.

The one page which my team went with was "Swordsage: Oakwood Adventure", a game developed by Alexander Saffigna-hayes, a friend and colleague of mine.

Alex's game was a continuation of his platformer prototype done earlier within the semester so much of the foundation was already laid out. It was simply a matter of discussing who would fulfill which roles and how we would organise it in a manner that suits everyone's busy time tables.

Just to provide a bit more insight though, the group formation was done in a workshop class where three of us, who were previously acquainted from different classes, got together and showed each other our one sheets and one pages. There we decided to go with Alex's because it seemed reasonable to complete within the time frame and it was also one that we all seemed interested in.

The work was divided into three sections: general coding and sprite designs, level designer, and special effects plus sound. I was in charge of the level design whereas Alex was in charge of general coding and sprite designs, and Luke was in charge of the effects and sounds.

Within a few days of the group being formed, I had developed a time table to go by, setting deadlines for when we wanted to get things done and playtest them. This was submitted as part A for assessment 3.

The following screenshot will showcase the foundation that Alex laid out:

These were the basic platforms and sprites that Alex had already obtained prior to beginning assessment 3.

Upon starting assessment 3 however, Alex gathered more sprites for us to use:

With these sprites now added to the project, I made a small segment to get players started.

The following segment wasn't screenshotted, however, it was used as a playtesting point where we experimented the existing code and flow of the gameplay.

Video of testing:

Here we can see that there are still some bugs regarding the AI movement, however, the animations work smoothly and the intended game progression works out smoothly too.

This sums up my post, I will now be logging off. See you in the next post.

[smallnim]

Racing Postmortem

This post is about my racing game where I will demonstrate, explain, and evaluate my development process as well as design reasoning. Like the previous postmortem, I will also be referencing segments of Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition (Fullerton, 2018) and how it has helped me throughout the development process.

Like always, I started off with a playcentric approach, involving players in the design process from the start to finish (Fullerton, 2018). I did this by thinking of player experience goals, something that players should and would want to experience while playing the game. In most racing games, people would want to choose their own car to add a sense of uniqueness to it, so keeping this is mind I found 12 different car skins for players to choose from which will be taken out of the NPC car skin options, keeping it limited to only the player once selected. In addition to this, another experience that many players enjoy in racing games is a nitro feature. Knowing this, I decided to include one in my own game for players to enjoy and use for gap closing and distancing.

In addition to the playcentric approach, I also worked with formal elements, specifically rules, resources, and conflict (Fullerton, 2018). The specific type of rules which I have used for my game are rules that restrict actions and determining effects. I used these by limiting player movement from passing map borders and driving over environment objects (trees and such). As for determining effects, if players are not driving on the road and drive on the surrounding environment, they will be slowed down or affected in other ways depending on other things they collide or come into contact with. For resources, there is a build up of nitro, health percentage, and time. As for conflict, I had NPCs that the player would have to go against and on top of that, the environment contains several obstacles that can slow the player or cause them to lose instantly if not careful enough.

Lastly, on top of resources, I also utilised dramatic elements, specifically challenge (Fullerton, 2018). The challenge of the game is that players only have 1 life and so they must be aware of everything, merging action and awareness together to perform at their best in order to succeed in the game. Players will also require skill, however, that can be developed through a series of play throughs as it is not expected that the game is completed in one session.

Now with that said, I will go on to reflect about the end result of my game.

The game that I was working on was unfinished, however, I am satisfied with the knowledge I gained while working on the different aspects of it. I would have certainly liked for my game to be finished, however, due to the lack of free sprites with similar art styles, it set me back a lot and made it difficult to make a huge map without having repeating sections. I was able to complete a start menu, car selection scene, and a testing scene for where the player would spawn as well as the NPC opponents. On top of this, I also made a still scene of what I would have liked the game to look like. The components of the game that I worked on were crucial to the overall foundation of the game as it sets the player in, however, I would have liked to at least made a short segment of the actual racing part of the game. If I could redo this, I would have looked for sprites first before deciding what type of game to do, however, that may have changed the game overall and it may or may not have been better than this idea which I'm proud of.

I will now be signing off now, however, underneath this there will be a video and screenshot of my work.

Completed sections:

Code:

Sample Scene:

Reference:

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

[smallnim]

One Sheet + One Page (Assignment 2)

Throughout the semester we have been developing game prototypes to better our knowledge and understanding of games. Using these prototypes, our second assignment instructs us to make a game design document based on one of the prototypes. This game design document has two parts which are a one-sheet and a simplified one-page game design document.

The prototype which I based this assignment on was my racing game, Fuji Ascent: The Climb to the Top.

For my one sheet, rather than showcasing all the features through texts, I wanted to include them as their respective sprites where possible while also adding to the overall presentation of the one-sheet rather than just cramming everything in. On top of this, I wanted to make it obvious what the one-sheet was showcasing which, in this case, is a racing game. I hoped to achieve this by showcasing a sample gameplay screenshot within the center while adding onto this with features around the one-sheet such as the cars and the road in the background. Also adding minor details such as the tires instead of dot points. In addition to this, I wanted to keep the overall theme of it similar to the game so I used the same font and colour schemes which in my opinion makes it seem more appealing. Below these sections of text will be an image of the one-sheet.

For my one page, I wasn't too sure what to do so I just comprised a small document showcasing the sample gameplay and describing the features visible in it. On top of this I wanted to follow a similar theme with the game however it would have made it difficult to read. The structure of it was a little messy in the end, however, I think it covers the general basis of the features and conveys enough information to attract others to work on the project. If there was something I would have changed about it though, it's that I made it using adobe illustrator. It was difficult to work with and things weren't coming out the way I wanted them to which set me back a lot. If I had more time I think I could have done something a little neater however I'm still satisfied with it. Below these sections of text will be an image of the one page.

One-sheet:

One page:

This sums up my assignment 2. I will now be signing off, see you in the next post.

[smallnim]

Racer Development Post Update

This is an update post of my development with the racing game.

Today I have completed following the steps provided on the workshop document. It was relatively easy and straight forward, however, there were a few minor inconveniences which came about due to my mistakes with the z order and object creations however they were fixed for the final gameplay as shown in the video below:

Some features that I decided to leave out were the score system and the paused scene as I wanted to begin development of my own racing game already.

Since I will be making my own changes to this, I will now be logging off to work on it.

[smallnim]

Racer Development

In the latest workshop, we were given a new game to begin development on which is a top-down racer game.

To start off the development process of the game, I downloaded the assets provided on canvas and began following the instructions on the word document.

The video below is a demonstration of the game after following the first few instructions.

Since this is just the beginning, I will need to put in more work to complete the game demo before making my own adjustments.

I will now sign off to complete the work, see you in the next post.

[smallnim]

Asteroid Shooter Postmortem

This post is about my finished asteroids shooter where I will demonstrate, explain, and evaluate my development process as well as my design reasoning. Furthermore, I will also be referencing segments of Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition (Fullerton, 2018) and how it has helped me throughout my design process.

For starters, to take on a playcentric approach, Fullerton (2018) states that I must involve players from the beginning of the design process to the finished game. An effective way of doing this is by starting with player experience goals. So with this in mind, rather than having players aimlessly flying around and shooting asteroids with no end goal, I decided to have a backstory to provide context for the game in my elevator pitch which was that planet Jupiter blew up. This was a starting point to get players engaged by giving them a backstory about the game and the goal set for the player. As for the experience itself, as stated previously about having players aimlessly fly around and shooting, I decided to set it so that the asteroids would come in waves rather than spawning randomly and causing panic. On top of this, rather than shifting the genre to a classic shoot 'em up game, I decided to keep the free movement and aiming of the ship to allow players to not be punished too badly by letting asteroids slip by which causes them to miss out on points.

In addition to the playcentric approach, I took note of the formal elements explored in chapter 3 and utilised elements such as rules, resources, and conflict which play a heavy role in defining the game. Such rules involved restricting player ship movement from leaving the screen and player ship firing too many bullets. As for resource elements, I incorporated a health system and a timed wave progression. As for conflict, it was just the generic asteroids, however, I had different variations of the asteroids such as a fast one, a regular one, or a large one which splits into two regular ones.

Furthermore, I incorporated challenge into the game. I did so by keeping the mouse controlled ship. Rather than adding keyboard controlled movement, I figured that by using the mouse cursor as movement instead it would server as a challenge by forcing players to think twice about their approach into the bombardment of asteroids, needing to think about time and space when firing asteroids while also keeping a safe distance.

Lastly, I also relied on chapters 9 and 10 which were playtesting and functionality. To ensure that the game was functional at a base level, I had friends and colleagues test out my game without providing context as to what they should do. Upon first launching the game, everyone understood that the goal of the game was to control a ship and fire at asteroids, however, players were clueless as to what else to do or why they had to do this. This ties back in with the backstory I provided for context within my elevator pitch. Ultimately though, through having them playtest different stages of the game, it was understood that the game was functional as people quickly grasped the concept of the game and the goal. I helped make the goal clearer by adding small aspects to the game screens which wouldn't tell directly, but rather hint at what they could be about such as having a score system which tallies points depending on asteroids being shot and a timed wave system to hint at a wave defense like game.

Now, with all that said, I will talk about my reflection of my final game and what I would change.

Overall, I'm rather happy about the state of my finished game as it is, however, if I could change something about it, it's that I couldn't develop a difficulty adjustor system for the oncoming waves without needing to setup a different scene, so if I could go back and change something, I would just setup a new scene instead of not having the system in place at all. In addition to this, rather than a score system, maybe have a "remaining asteroids" count or something instead to better suit my game as it's more like a wave defender instead of an endless shooter. Despite this though, I had learnt a lot throughout my time developing this asteroids shooter game and am looking forward to creating more games in the future with the skillset I learned from this one.

I will now be signing off now, however, before I do, below this will be a video and screenshots showing my gameplay and coding.

Video showing gameplay:

Screenshots of code:

Reference:

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

[smallnim]

Racing Game Elevator Pitch

Title: Fuji Ascent: The Climb to the Top

Context: Ever since Ren was a child, she had dreamt of becoming a famous driver, one who would dominate every racing track known to man kind. It has only been a month since her 22nd birthday, and yet she is already preparing to take on the last obstacle which stands between her and the title of world's most elite racer. Ren, also known as the Revving Devil now comes face to face with the Fuji Ascent, a dangerous race track that spirals to the top of Mount Fuji, only held once every 5 years.

Image Assets: The below sprites are only a teaser of the assets I will be using to develop this game.

Control Diagram:

Top-down camera control

Acceleration

Braking

Maintaining speed

Nitro function

Gameplay:

Racing to the end of a set course

Racing against multiple other NPCs

One life playthroughs

Unique features of the game will involve:

Car Health Percentage

Nitro Gauge

Competing NPCs

[smallnim]

Asteroid Shooter Development

This is an update post of my development progress into the Asteroid Shooter.

Today I have completed following the instructions on the workshop document. Although I ran into a few troubles due to some steps being outdated, it was easily solvable by testing out each different step and how they worked. On top of this, some instructions did not work so I had to either disable or remove them as shown below:

After completing all this, the following video will demonstrate me completing all the steps including a few additions of my own design such as splitting asteroids.

Now that I have completed the basic necessities, I will post a further update when I have added in a start screen, win condition, asteroid collisions and my own assets.

Now signing off, see you in the next post!

[smallnim]

Asteroid Shooter Development

For today's workshop, we have been tasked to start development on a new game which will be an asteroids shooter game.

To start off this process, I have downloaded the instructions provided on canvas as well as the assets and followed them accordingly.

The video below is the beginning point of my game where I follow the first few instructions of adding a player ship and make it rotate accordingly to where the mouse cursor is on the screen.

As this is just the beginning, I will post a follow up of the game after the instructions have been followed to demonstrate my understanding of GDevelop.

Now signing off, see you in the next post.

[smallnim]

Asteroids Elevator Pitch

Title: Operation G.S. - Earth's Last Line

Context: Due to unknown circumstances, the fifth planet within our solar system, Jupiter, has mysteriously been destroyed and its debris is now flying face first into Earth. As a last line of defense, all the world leaders have decided to work together to create a special task force in engaging the asteroids flying towards Earth. As one of those selected for the task force, you will be in charge of piloting a spaceship and shooting as many asteroids as you can to stop them from plummeting Earth's surface.

Genre: Shoot 'em up

Setting: Outer space

Audience/Demographic: The target audience for this game is people who are entertained by retro shoot 'em up games such as space invaders. As for the demographic, the game is catered for young kids and teenagers between the ages of 8 to 16.

Image Assets: The below sprites are only a teaser of the assets I will be using to develop this game.

Control Diagram:

Mouse controlled airship

Left mouse button to shoot

Gameplay:

Wave shooter

Power ups

Increased difficulty

On top of the already mentioned aspects of the game, there will be three more unique aspects about the game:

Earth health (if too many asteroids get past you, you lose the game)

Chosen beginning difficulty which comes with its own score multiplier

Score saver for those who wish to see improvement

[smallnim]

Platformer Postmortem

I have now approached the end of my platformer. Although I have achieved less than what I had planned to, reality presents challenges harder than expected but that just means that I have to push for more next time.

Throughout my experience with GDevelop, I have been supporting my development process with understandings from Fullerton's Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition (2019). Segments of the book that I have read so far which have had a huge impact on my design process were chapters 2, 5, 6, and 7. Although everything I have read so far has helped, these chapters especially made it possible to develop what I have so far.

Chapter 2 gave me insight on approaches to make the game more engaging for players which I believe I have achieved (Based on friends and colleagues playtesting and providing feedback). Chapter 5 helped me gain a better understanding on the properties of my game and how their separate complexities add onto the game. Chapter 6 helped me in conceptualising my idea by utilising different methods to help me break apart different game ideas, especially the mind map. As for chapter 7, it further expanded on chapter 6 where it highlighted the importance of visualising core gameplay from my original game concept. This helped especially as I was losing track of myself in the various ideas I had come up with, so without this, I probably would not have a functioning game if I had focused on special features rather than the core gameplay.

Now reflecting on my game, using what I just mentioned about the chapters, if I were to change how I developed the prototype, I would definitely prioritise core gameplay before moving onto aesthetics and other various features of the game as I limited the amount of time I had to actually piece the game together after adding numerous features. As for the design aspects of the prototype, I would have tried to incorporate more of the simple designs and features obtained and learnt from my workshops as those alone were enough to make a decent game.

With all that said, that concludes my platformer postmortem. Thanks for tuning in, I'll be signing off now, see you in the next post!

References:

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

[smallnim]

Platformer Game Update

The above video is a small demonstration of the game so far.

A few features I have implemented into the game that were different to what was taught was a gun and shooting system so that players have another way to get rid of enemies rather than just jumping on them. In addition to this, I added new enemies with unique movement.

More ideas that I want to add to the game are ladders, vines, bouncy plants etc. I feel like this will give players more joy when playing the game as they have more to experience and their own choice of approaching the game.

I am still contemplating about what else to add as there are so many ideas to add but I am currently at a race with time as this is expected to be playable by Tuesday the 22nd of August.

I also had a colleague playtest my game to provide feedback. The feedback mostly suggested minor improvements to make the game feel smoother by having better transitions and forces behind animations. This was to be expected as the game was incomplete, but nonetheless feedback is always appreciated as it is important to not overlook anything no matter how small they may be.

With that said, I'll be signing off to finish more work, see you in the next post!

[smallnim]

Platformer Elevator Pitch

A playcentric design process. Fullerton (2018) highlights that it is key to involve the players in your design process from the concept to the finished game. Fullerton states that the best way to introduce players into the design process is by setting player experience goals.

With this in mind as well as the genre of the game, a player experience goal that I would set up within my game would be for players to have multiple ways to navigate through the world rather than being confined to a simple jump mechanic.

In addition to this, Fullerton also states that if you wish for the players to engage with the game you have to give these elements meaning. To give these various means of navigation a purpose, I will create puzzles for players to engage with by utilising different jumping methods.

Now, with all that said, I will present my platform elevator pitch:

Planet-86, this is a game situated on a planet which closely resembles that of planet Earth. As an alien operator working for the [CLASSIFIED] organisation, you have been tasked to navigate through foreign lands and to eradicate any potential threats that may harm the rest of the crew upon landing. The goal of this game is to find a secure location for the crew to land at and clear as many hostiles as possible.

Genres: Platform, Action

Gameplay:

Vertical and horizontal map progression

Puzzles to progress with the game

Various enemies which players can avoid or defeat by jumping on top of them.

Various unique methods of traveling through utilising the environment.

Mechanics:

Basic jumps (can be altered from environmental influences)

Setting: Earth-like planet

Audience/Demographic: The target audience for this game is people who are entertained by the concept of space and the undiscovered worlds behind them. As for the demographic, the game is catering for teenagers between the age of 13 and 18, however, the game is not limited to just these ages.

This concludes the end of my post.

References:

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

[smallnim]

Development Post

Continuing from last time, today I have completed following the workshop document instructions.

I have demonstrated my understanding of the content in the video above where I have developed my own platformer scene which demonstrates the basic features.

On top of that, I also demonstrated my understanding by adding a feature where the player is reset to the spawn position if they collide with the slime while running at them.

Now moving forward, I will be presenting an elevator pitch next week of my own platformer game idea. On top of this, I will also be starting the development process for the game idea next week as well, posting a few updates on the progress and state of the game.

I will now be signing off, see you in the next post.

[smallnim]

Development Post

This is the beginning of my GDevelop experience. Today we were tasked to create a platformer game by using the provided assets and following the workshop document given to us.

The video above demonstrates the result of the first few design processes which were inserting sprites, assigning sprites with different movement, and changing the variables of the player.

As this is just the beginning, I will post a follow up of the game after the instructions have been followed to demonstrate my understanding of GDevelop.

Signing off now, see you in the next post.