HarrisonIGB220 @harrisonigb220 - Tumblr Blog

Week 13 - Assignment 3 Postmortem

Welcome back to a very special and final GDevelop-ment blog. This week I will be discussing my thoughts on Asteroid Field Escape, some feedback we got since last time, the things I liked, and where I would see the game going if development was continued.

Further Feedback

Last time I was discussing how we tested three different individuals within our class and the difficulty was too high which made it very hard to get conclusive feedback on our features. Well, it turns out the changes we made to the screen size, and movement speed paid off as almost everyone was able to complete the game and enjoy the features.

The powerup was one of the standout features for our playtester as they enjoyed being able to become the ship that they destroyed. There was some misunderstanding on how they acquired the powerup in the first level but by the second they understood what was occurring.

The boss fight was also a hit with it leaving the playtesting session on a high note with the difficulty being a good balance, with most playtesters surviving on very minimal life.

The Good

While not being my initial project, there are many things I really enjoyed and believe turned out very well.

The amount of enemies and range of different enemies added quite a bit of variety for the player, not only to fight and overcome, but also to play as.

Movement was something that also grew on me quite a bit, albeit had mixed reactions from playtesting, I felt like the weight of the ship and drag felt like you were in space unlike plenty of other games which have such precise movement that it doesn't feel like zero gravity.

Finally, the boss level. I absolutely love this level, and the use of the edge mechanic which the player could use to their advantage now being flipped and the boss is the one using it to add difficulty. If we had more development time I would have loved to create more bosses as hard but fair challenges for the player to overcome.

The Potential

If I was to continue developing the game there are several additions I would include into the game, and some changes I would make:

1. Add in a Beastiary which would allow the player to see how many pirates they have defeated, and once defeating so many they would unlock the ability to star the level as that ship.

2. Adding in proper fullscreen support

3. Adding more levels, bosses and enemies

4. More indepth cutscenes that feel like an addition rather than an after thought

5. More unique sprites

With these additions and changes I believe the game would be extremely fun and improve off what already makes the game enjoyable in its current form.

Finale

Well, it has been a long journey and I'm grateful for everyone that has been following my development blog as I've learned my own lessons in Game Development and how to develop a prototype for a game as a team.

Live long and propser!

#Week 13 #Assignment 3 Postmortem

Week 11 - Playtesting

Hello and welcome back to my IGB220 GDevelop-ment blog, where I have been showing off and developing my approach to game design. This week I will be covering something briefly talked about in an early week, Playtesting.

Playtesting is the largest part of my final assessment for this subject, as it is important to not only learn how to playtest properly, but also to learn how to take critique which can help improve the game drastically. It is a difficult task and is very important to begin early.

The Contestants

For playtesting we decided to go with fellow students within the IGB220 class, as almost all students will have a solid amount of experience with different kinds of games.

We selected three individuals and began testing our current build of the project, where they had no prior knowledge to how the game played or what was instore for them. We ran them through a script which would help introduce them to speaking out loud and took down notes of what they say and interactions. It was my duty to run the playtesting session.

Alpha Results

The results of the playtesting session were quite obvious: the game was too hard. This was due to a couple of different factors such as:

1. Movement being too quick from 0 to 100

2. Too many enemies, and objects on the screen

This lead to several problems such as visibility and also resulted in no contesting being able to complete the game, something I have been able to do.

Due to the results of this playtesting session, we as a group decided it would be wise to take the feedback we got and to develop the final build of the game for playtesting with a set of 5 different people. The reasoning behind this decision is because the difficulty was so high, it meant we couldn't get any proper feedback about unique features of the game, such as edge warping, power ups and the boss fight. If we didn't get any results about these features, we couldn't definitively say if he have achieved the goal of the feature.

Fixes

To remedy these glaring issues we set out to make the game scenes larger to allow the player a larger amount of space to manuever their ship around, which would not only fix the movement being to quick but also the plethora of objects on the screen.

Finally, with more room this allowed for more enemy ships to periodically spawn which would intern allow playtesters to try out many different ships.

Finale

To conclude for this week, we all set ourselves each work for the week with tweeking numbers, fixing important issues, and any other minor changes we could squeeze out before the next playtesting session. Stay tuned for next week, which will be the final post.

#week 11 #playtesting

Week 10 - Assignment 3 Development Progress

Hello, and welcome to Week 10 of my GDevelop development blog. This week I will be covering a slightly different topic as alluded to previously, where I will be talking about my currently development with the Assignment 3.

What is Assignment 3?

Assignment 3 is a group project where 2 to 4 students team up together to work on a single game that has been been designed based on their assignment 2 one page and sell sheet. These are usually based off those prototypes that have been done over the semester; platformer, asteroids and racing.

My Group

When selecting a group I chose a group which was planning on doing a similar project as myself, an asteroids based game. This was to help keep interest in the project and want to work on someone elses project, since I knew not everyone would want to give up on working on their design. The group consists of Casey, Tim and myself. For this project we chose Caseys' game design.

Chosen Game

Asteroid Field Escape is an isometric bullet where you a mining ship thats warp drive has failed within an asteroid field, and you must manuveur and destroy asteroids and pirate ships. Upgrade your ship by destroying pirate ships and mining their parts. The game is a level based game and will have 4 levels (including a boss battle)

Development

When developing the project we split the work into multiple different parts. Casey had developed a good initial prototype from earlier in the semester, however it still needed quite a bit of work to reach the standard of what we wanted to achieve. The work was split into 3 different workloads:

1. Levels - which Casey was tasked to work on

2. Enemies - which Tim worked on

3. Boss and Menu - which I was tasked to complete

Everyone was able to finish their work and merge it together via GitHub, which I have been teaching them how to use. After completing this weeks work, we needed to set a goal for next week. Using these parts that have been developed we decided to piece them all together over the next week to create a cohesive game for playtesting.

Finale

That is it for this week! Stay tuned for next week were I will be discussing the results of our prototyping and the impacts of that on the game.

#week 10 #assignment 3 development progress

Week 9 - Racing Post Mortem

Hello fellow GDevelop enthusiasts and welcome back to Week 9 of my blog. Today, I will be discussing my thoughts on the development of MotoStyle, things I liked and others that I struggled with or didn't like.

The Good

When initially pitching the idea of MotoStyle, I pitched it as a small open world game. However, as discussed previously it required tons of work, time and experience which I didn't have. So I was genuinely pleased with the adjustments that I made to the game into a level based linear game, where you would still deliver but the levels would get harder as you progressed. It fit really well together, and I also enjoyed getting to level 3 and the game was throwing in road blocks and slow down platforms which would make it hard to get a good time.

The Complicated

As explained previously in the pitch for MotoStyle, I am not familar with many racing games, especially top down racing games, which made it quite difficult for me to create a prototype that I was completely happy with. After thinking about what I could have done better to improve the quality of what I was able to create, I narrowed it down to one concept, playtesting or lack of playtesting.

While I tested as much as my previous prototypes, I needed to test more, as I didn't have that background knowledge or passion for the genre. What I needed to do, was similar to what Fullerton (2019) describes where I could have conducted a playtesting session of Discord with some of my friends who are interested in racing games. Even though Fullerton does not recommend playtesting with friends due to feedback being obscured due to having a connection with the person, I believe I would have been able to get easy feedback to help improve certain features, such as driving.

Driving movement was something I struggled with quite extensively to feel natural and not too weighty or not too stiff, and resulted in the game feeling clunky to play. Whether a technical limitation from GDevelop or a lack of playtesting I will never know because I didn't test the game with enough people to get a true idea on how to improve it. It could have been something as simple as making the game screen larger, and expanding the lanes to give more room or something else but I didn't do the testing.

One thing I will take away for when it comes around to the group assessment is playtesting, so we can try make the best game possible based on real feedback.

Finale

That’s all I have for this week, stay tuned for my next post where I will be discussing about the group project for the final assessment for this semester. Take care!

Source

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition (4th ed.). A K Peters/CRC Press. https://doi-org.ezp01.library.qut.edu.au/10.1201/b22309

#week 9 #racing post mortem

Week 8 - Racing Development Post

Hello, and once again welcome back to my GDevelop blog. This blog I will be covering my development of the MotoStyle, the issues I have encountered, testing and the results of my labour.

Development

When beginning development of MotoStyle and it's open world I needed to find many different assets that could be used to create the roads and environment for Speed City. When searching for the assets however, I came to realize the scope of the project I was undertaking and how much would be required to make even a basic prototype for my testers to give feedback on. This is because of the rules that each object would have to obey to, something I've been including into my design philosophy since reading Fullertons readings, including traffic, and other objects that can be interacted with. How would traffic move around the city? How would they interact with other cars if collided?

Because of all these increasing rules that kept appearing, I decided to change my approach of the open world, into a more hub-based game. It still followed the design of the pitch about getting to the delivery location as fast as possible, however you would return to the hub to select another mission or retry.

This freed up lots of development time and allowed me to focus on the gameplay itself.

Some changes were made to the gameplay also, instead of being able to take the shortest path, I took the practical excersize we worked on in class, and expanded on that. To give players skill expression with finding the fastest path, I implemented boosts which could be missed and would affect your overall time allowing for future replayability.

Testing and Iterations

When testing the game myself I really wanted movement to feel fluid, especially when driving in between cars to try and hit a boost or avoid traffic. To do this I had to focus on both the hitbox and the turning speeds. The initial movement that was implemented from the practical felt too slow for the arcady feel I was trying to go for, and for the van model I selected. Firstly, I increased the acceleration and deceleration, which felt better, however when changing directions still didn't feel reponsive enough. So, I increased the deceleration to be higher than acceleration and this fixed the turning issues almost completely. Next was the hitbox, and based on my previous experience with hitboxes, the perfect hitbox is always just smaller than your actual character model to provide some leeway.

Now that I have a working prototype I'm happy with I get one of my friends to test and provide feedback. Here is a list of the main critiques of Motostyle:

1. Lack of feedback with boost

2. Boosts set to specific times

3. Instant death was too punishing

So the first thing I wanted to do was to make the boost feedback more responsive. To do this I needed everthing else that moved to respond to the boost, not just a hidden variable which would make the finish line appear earlier. I did this by applying the boost variable to all the moving objects for a timed duration.

Next was the boosts being set to specific times. This was something I overlooked, and makes a lot of sense because they spawn exactly the same time each time, you won't be able to get a better run ever. So I change it to spawn randomly in a time frame, to give the levels more replayability.

Finally, I created a health system which would allow for your vehicle to take a couple of hits to feel less punishing when you accidentally made a wrong manuever.

Finale

We have once again reached the end of this development post. Stay tuned for next week where I will be covering the post mortem of the development of MotoStyle. Until then, take care!

Sources

#Week 8 #Racing Development Post

Week 7 - Racing Elevator Pitch

Welcome back to another GDevelop Blog. This week I'll be pitching another game this time based on a Racing Game concept for GDevelop.

I am not as familar with many racing games, outside of games like Need For Speed, as I am with other genres so I believe it will be an interesting challenge developing a fun and unique game.

The Pitch

MotoStyle is a top down time based racing game where you are a driver for MotoStyle Delivery, and you are tasked to delivering the goods to a specific destination before running out of time. You will be travelling around Speed City, which will have different boosts, time extensions and power-ups to collect to help you arrive on time.

Unique Game Concepts

1. An open world design which allows the player to work out the fastest way to complete the time trial.

2. Power-ups populating the world to promote experimentation

3. Exciting gameplay due to time restrictions and gameplay built around making the most of that time.

Gameplay Loop

The idea for the gameplay loop of MotoStyle is that you will accept one of a few different types of jobs, ranging in difficulty, and it is your task to try and get to the destination before the time ends. It is up to you to work out the correct way to get to the destination on time, and use the power-ups available to get there. If you are to fail, you will need to retake that task until completely the job. Traffic is also another factor to consider since cars will damage yours and if you take too much damage, that's game over. A series of different jobs will be available at any time and to win the game you must complete them all. MotoStyle will have no permanent progression and will be focused more around learning the world and developing your skills and as a proficient driver.

Finale

Once again we're at the end of a blog, thank you for reading and I hope you enjoyed my pitch idea for an open world racing game, akin to an earlier era of gaming.

Next blog I will be showcasing my development on the project, until then, take care!

#Racing Elevator Pitch #Week 7

Week 7 - Space Jockey Post mortem

Hello and welcome to Week 7 of my blog. Today I will be discussing my thoughts on the game I have been working on over the passed two to three weeks, Space Jockey. Some topics I want to cover this week are: the things that worked really well, complications in the development of the pitch, and the potential future for the game.

The Good

To start off there was a lot I really liked about this game, especially over time compared to my previous project, Castle Runner, which I felt had more issues with its execution after further development.

Something I really enjoyed was the movement and overall feel of the game, which I fine-tuned over the course of the last weeks. This allowed for some precise shooting for the user and made the current game quite easy because of that, which is good! Since I had such a solid foundation for movement it allowed me to worry about other things like different ships and a boss inclusion.

The boss was something I believe worked quite well, feeling quite epic in size and also had challenge where it would shoot bullets and then change directions every couple of seconds to change the pattern.

The differences between the ships and the way they shot was something that worked out quite well and defined each of the ships and what they excelled in. The Ballista was my prized ship, shooting like a shotgun with multiple bullets which was quite satisfying to use.

The art was a big plus, which I purchased from Itch.io from pzUH which gave me some really nice side-scroller art that I could use for the project.

The Complicated

One thing that I definitely overstepped my boundary with was the RPG elements. Once I realised how much work was involved with creating a system which could remember what I had bought in a shop and then applied that to my current ship I decided to not even tackle it and just follow the advice from my readings of Fullertons book (2019) where I would create a solid design foundation and structure, which I would further refine those details to help improve the core features and fun.

Patterns was something else I wanted to encorporate into the design but realised how complicated that would be, since as far as I could work out, GDevelop doesn't really have an easy way to implement something like that. So I had it randomly generated spawns which feels bland compared to a pattern based movement system.

The Potential

As I was saying before I am very pleased with the end result of my project so far, and am going to continue this idea for my assessment where I need to create Sell/One Sheets of a game design and try to pitch that to someone else for the group work later, as I believe the idea really has potential.

If I had time to continue working on the project I would definitely start with RPG elements and creating a Shop and item persistence so I can start expanding on that side of the pitch. After that I would focus more on enemy AI and creating a couple of stages to showcase the further potential of the game.

Finale

That's all I have for today and I hope you enjoyed my perspective of the project after developing it for some time. Next time I will be discussing a pitch for a racing styled game.

Until then, take care.

Source

pzUH (n.d). Side Scrolling Space Shooter 2. Retrieved from https://pzuh.itch.io/side-scrolling-space-shooter-2

Fullerton, T. (2019). Game design workshop : a playcentric approach to creating innovative games (Fourth edition.). CRC Press, Taylor & Francis Group.

#asteroids post mortem #week 7

Week 6 - Space Jockey Development Post

Hello fellow GDevelop enthusiasts, and welcome back to another development post of my current project Space Jockey, an RPG Shmup with progression.

Development

This past week I have been working on following Fullertons design process mentioned in Chapter 10, about where he discusses Foundation, Structure, Formal Details and Refinement. Over the week I wanted to focus on creating a solid foundation and structure for Space Jockey where I could test fundamental features and rules to go with such as movement, shooting, and enemies. I didn't plan on implementing any RPG mechanics into the foundation due to unneeded complexity but still experimented with core mechanics to give an understanding of what I could do.

For the foundation, I wanted to implement what I believed were core features, enemy spawning, movement of your ship, different ship types, and boss mechanics. Different ships allowed for the concept of what RPG mechanics could result to without implementing proper RPG mechanics into the game taking up unnecessary time. Movement was something I wanted to get right and several different iterations where gone through to develop which will be discussed in the next part.

Due to this focus on base features, it allowed me to create a playable game with a clear direction of what I wanted to achieve.

Testing and Iteration

Testing was a major part in the refinement of Space Jockey, and this was very obvious in the iteration of movement and difference between ships.

Movement was initally designed with the intension of using the WASD keys which would then free up the other hand for shooting and abilities. This worked quite well, especially when I put in drag so the ship didn't instantly stop on the spot giving them weight. However, after testing this movement with enemies it became quite hard to make small adjustments for shooting and was quite tedious since percision shooting was a must and it felt like you were fighting the game. So, I changed the design to mouse movement where the ship would follow your mouse at a set speed. This worked out quite well, and fixed the issue of making small adjustments to hit your target.

Next was creating three unique ships which fundamentally felt different to play. This was the testing waters for RPG mechanics which could be implemented in the future. Three ships were created, Speedster, Marauder and Balista. There was several factors in play to make the ships feel unique, speed, bullet pattern and frequency. Speed was easy to implement just having a fast ship and the other ships being slower. Bullet Patterns and Frequency was the big one, where I had a traditional single bullet which came out of the Speedster, the marauder rapid fired multiple bullets, and the balista launched a cone of bullets. The Balista and Marauder went through different stages, where the Balista cone was reduced after testing due to it feeling underwhelming, and turned into more of a shotgun style pattern. The Marauder initially had its two bullets to close together which made it feel like the speedster, so seperating there points gave it this gatling gun effect.

Finale

That's all I have for this week, stay tuned for my next post where I will be discussing my further development on Space Jockey and a postmortem of the project. Until next time!

Source

#Asteroids Development post #Week 6

Week 5 - Asteroids Elevator Pitch

Hello and once again welcome to my GDevelop-ment Blog. Today, I will be explaining my pitch for game I have been developing and thinking about before I even started this course but now have the opportunity to capitalize on that.

I love the idea of Space Shmups (shoot-em ups), however I always feel like it's missing something since there are temporary power-ups that you can acquire to make yourself stronger, but I love persistence which is why I love Diablo and Path of Exile.

The Pitch

Space Jockey is a side-scroller looter shoot-em up where you will be playing as a member from a space squadron where you goal is to explore a wormhole, however you become trapped and must fight and evade an ancient alien race to return home. Collect loot from your enemies and upgrade your ship to help you combat larger and stronger foes.

Unique Game Concepts

1. Strong progression due to persistent upgrades to your ship acquired from loot from your enemies.

2. Unique builds and playstyles allowing replayability

3. Different ships for you to master and fast paced combat to keep you on your toes.

Gameplay Loop

The general gameplay loop of Space Jockey will involve the player heading out into the endless wormhole, where they will fight many ships, general fodder, mini-bosses and bosses. When destroying an enemy ship there will be a chance of loot to drop which can be acquired. To finish the level the player must defeat the boss of that level. Once completed they may upgrade their ship and prepare to head out again to try and escape the wormhole.

That's all I have for today, thank you again for reading my Blog and next time I will be showcasing what I have worked on and how I have evolved the game over testing.

#asteroids elevator pitch

Week 5 - Platformer Postmortem

Welcome back to my GDevelop Game Development Blog! In this post I will be going through my thoughts of the Platformer I created which was meant to be inspired by platformers such as Celeste and Metroid, where I will discuss what I believe worked well and could have been improved or changed. I will be condensing this analysis down into three different parts:

1. The Good: which will talk about what I think worked well and received positive feedback from

2. The Bad: things that I believe didn't work out as envisioned.

3. The Potential: a thorough dive into the features and where I would have gone

The Good

One of the things I really believed worked well was followin formal elements layed out by Fullerton, such as Objectives and Rules. When designing the pitch, one of the things I really wanted to emphasize was the exploration and reward of the world, through the use of power-ups and gated content. This was done by limiting where the player could go, and by changing the rules bound to the player like 'can only jump once', a power-up was able to adjust that rule to 'can jump twice'. This aspect I really enjoyed and wanted to become quite apparent from the get go when playing the prototype.

The next was the world and the art, however I cannot really take credit as it was created by another user, but allowed the world to feel more real than a basic prototype could have been using stock sprites from GDevelop.

The Bad

When creating the pitch of the game, I attributed the design of the game to Celeste, however I feel like I completely missed the mark of that aspect of the prototype. This was due to the style of movement, world, and camera angle which all affected the dramatic elements of the game. When discussing the story of the prototype it was about stopping the Undead King from corrupting the world, however while I liked the look of the world, the building of Dramatic Elements (Fullerton, 2019) using world building such as the environment, did not convey that but a more generic RPG world since there was no dark elements like dying plants or death, and the colour palette was quite green and purple.

The camera angle was another oversight by myself, since it made the game feel more like an RPG which limited what I could potentially do in the future with puzzle rooms, more closely resembling rooms from Celeste. The reason being is the camera would limit what you could see and hinder planning when trying to solve a movement based puzzle.

The movement was the next aspect I would have adjusted to make it faster and less heavy, to allow the player to make quicker and tighter movements. The camera would have needed to be adjusted for this to work correctly however.

The Potential

Now that I have explained what is good and bad about the prototype, I would like to discuss the potential of the game. As explained in the previous post, my game ended up turning out more like an exploration based game similar to Metroid or Hollow Knight, which while didn't fit with the initial vision I believe was executed quite well and if I was to continue developing the prototype, this is the direction that would have been taken due to the execution and implementation of staples within that genre, like Double Jump and power-up gated content.

Furthermore, I would have just expanded the current would I had created to be larger and feel interconnected, similarly to what it currently was, and give the player options to explore freely this world. There would be other scenes, worlds, that would be transitioned to however it would not be like Celeste with that individual room to room gameplay.

The End

That's all for today, and next time I will be discussing my pitch for an Asteroids/Shmup based game which I am quite excited for since I have plenty of ideas I believe aren't currently implemented in the genre.

See you next time!

Sources

Fullerton, T. (2019). Game design workshop : a playcentric approach to creating innovative games (Fourth edition.). CRC Press, Taylor & Francis Group.

#week 5 #platformer postmortem

IGB220 Week 3 / 4 - Platformer Development Post and Playtesting

Hello and once again welcome to the development blog of my platformer in GDevelop. The last couple of weeks I have been putting a heavy focus on the development of the project into making a working prototype to allow others to playtest the game and give feedback. When playtesting the initial prototype I received quite valuable and just feedback from participants which helped me focus and mold my project into something more enjoyable and complete.

Feedback

1. The movement and collision felt to stiff and some objects were bigger than their image

2. Their was no clear instructions on what came out of the chest when opening it

3. Some jumping sections were to hard

4. Lack of puzzles and direction

Some of these suggestions I completely understood and worked on, others I didn't agree on but took the opportunity to expand of concepts to further improve.

Provided Fixes & Iteration

My main goal was to solve multiple problems with simple solutions. The first was to focus on Formal Elements which help make up a game, as described by Fullerton, such as Objectives. Currently, my game had minimal exploration and puzzles which I wanted to emphasis as part of the world. To fulfil this idea, I created a new puzzle that rewarded the character for exploring once they unlocked a previous ability. By doing this it allowed me to indicate to the player there was more objectives in the game and make the world seem more rewarding world. The reward that I implemented for completion of the puzzle was the ability for the character to double jump which they could only acquire after the learning to shoot the crystal.

Now, with that implemented I could further give the player more objectives, such as creating another area for the double jump to reach the exit.

Next, was to adjust the collision present within the games world to be more fluent and didn't feel like you were constantly bumping everything. The main issue from feedback and my own testing was the corner sprites and the spacing of platforms. Due to the corners having a base square hitbox I needed to adjust the hitbox to match the sprite to allow the player to predict jumps correctly. This was immediately remedied with custom hitboxes and made the world feel more pleasent to jump around in. The next issue was the worlds spacing, and as seen in the picture above if not placed correctly the character would hit the roof and feel bad to jump around in. Through playtesting and iterating on the design I was able to create a platforming section which felt fluid. This process was used throughout the world.

Finally, I added text based instructions which would show when the player would open a chest for the first time to help guide the user on what the unlock does and how to use it.

World Building

With the feedback out of the way I was able to work on making the world feel more alive and whole. Thanks to the texture pack that I downloaded, I was able to put in some houses, trees and other doodads to help make the world come alive. This is a before and after of an area:

Current Game Thoughts

With this further design to the world, I came to realize I was creating a game more focused on the Metroid side of the game and less of the Celeste aspect. So, I made a conscious decision to reduce the amount of Celeste aspects in the future and showcase that form of the game in Puzzle Rooms. So the pitch will have changed from "Celeste meets Metroid" to "Metroid meets Celeste", where there is a large interconnected world with Celeste styled puzzle rooms allowing the player to challenge themselves with the abilities unlocked.

That's it for this week, thank you for checking out my development blog, next week I will be finalizing development of my prototype and discussing my thoughts on the process and what I would do next time.

Sources

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. ProQuest Ebook Central https://ebookcentral.proquest.com

#Platformer Development Post #Playtesting #pitchinsights

IGB220 Week 2 - Platformer Creation

Welcome back to another post of my progression with GDevelop over the course of my learning. During week 2 we were tasked to follow a tutorial on how to build a basic platformer from scratch (similar to what is provided by GDevelop) to help learn the basics of developing with the software. The tutorial stepped through how to make a playable sprite that can walk and jump, creating enemies, changing animations, and basic combat akin to Mario Platformers.

After completing the tutorial had been completed I wanted to make a some adjustments to the game and try implement some systems for my potential game development assignment. One was making the character change directions based on the way they were moving and the other was creating a simple inventory system that could be used for an upcoming game concept. Changing the characters direction was easy, I took what I had learnt from the enemy section about flipping their animation and did that while also creating new events to register button inputs.

Next was the inventory system, where I wanted to make a Interface in the top left hand corner that you could switch through when acquiring certain items in-game. To try figure out how to do such a system I went into the basic platformer game template by GDevelop and studied their Interface. By creating a GUI layer, I was able to stick the layer to the top of the screen so the inventory sprites would follow. Next I would create three individual sprites for each slot with different animations based on whether they were selected and what item they are holding. Using the buttons, num1, num2, num3, I was able to swap through each slot. Finally, I used collision with a sprite to activate acquisition for the item.

Thanks for reading my blog, stay tuned for my next post which will be an elevator pitch for my game concept I have been working on.

#week2 #GDevelop Experimentation

IGB220 Week 2 - Platformer Elevator Pitch

Hello, and welcome back to my GDevelop Blog. Today, I will be going pitching my Platformer that I have been thinking about for quite some time. I am an avid fan of platformers and Metroidvanias, so my concept may be somewhat ambitious for a first timer when using GDevelop.

Castle Runner is a side-scroller puzzle platformer where you will be playing as a nameless soldier searching for the Undead King within Maze Castle to put and end to his spread of corruption on the land. Explore Maze Castle by completing movement based puzzles interlinking each other, and unlock new and secret areas after acquriing special power-ups that can allow for each persons playthrough to take a different route.

Unique Game Concepts

1. No traditional combat, movement is the only challenge

2. Interconnected world

3. Replay value with finding secret passages

Below is a rough idea of the gameplay loop and how it will work when exploring Maze Castle. In this diagram it shows that their are interconnected rooms, puzzle rooms and secret rooms. Each of these are connected either naturally or by having a power-up to unveil a new path normally hidden away. When reaching the right room you can get a new power-up which can unlock these areas. Finally, the Undead King is the final boss and upon defeating ends the game.

That's it for this blog. Next blog will be showcase more work within GDevelop, and some playtesting of the results of the development.

#week2 #elevator pitch

IGB220 Week 1 - About Me

Hello and welcome to my IGB220 blog series. Throughout the next 13 weeks I will be documenting my experiences, processes and learnings during the course and developing a game in GDevelop.

Who am I? My name is Harrison Schuch and I am an Information Systems student majoring in Computer Science at QUT with an interest in game development. While my current career goal is not necessarily to work in game development, it is something I am extremely passionate about and given the opportunity wouldn’t pass up. I have been working on projects in the Warcraft 3 World Editor since I was 12 years old, delivering on some game concepts and failing on many others, due to its robustness and being provided a large amount of assets to play around with. I have worked on Tower Defence, Online RPGs, Wave Surival, and basic RTS games (Harrison Schuch, n.a).

Even though using the World Editor is considered modding, you can modify the base game so much you change the standard gameplay loop of Warcraft 3.

During the first week of my course I read the first couple of chapters of Fullerton’s Game Design Workshop book (2018) and it gave me some interesting insight, which I could reflect on my previous hobbiest work within Warcraft 3. One concept of particular interest was the idea of making the game for the player and targetting that demographic by making a fun gameplay loop. Just explaining this sounds particularly obvious however over the course of my experience of developing RPGs for Warcraft 3 you could easily lose focus of the gameplay for features and the world, and when finally playing it... it sucks. Fullerton (2018) provides a solution by involving playtesters constantly and allocating time to play your own game to keep the mindset focused on the players experience.

Sources:

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. ProQuest Ebook Central https://ebookcentral.proquest.com

Harrison Schuch (n.a). CroMoX’s Map Resources. Retrieved from https://www.hiveworkshop.com/members/cromox.201832/#resources

#introductory post

Trending Blogs

Recently Viewed Blogs

HarrisonIGB220