Untitled

[vi-r-gamedev]

About me.

Hi! I’m Violet, and I’m using this blog to chronicle my work/learning experience throughout the Bachelor of Games and Interactive Environments at QUT. Specifically, it’s a requirement for IGB120, but I hope I’ll be able to showcase work from other courses as well!

I’ve played a really wide variety of games (If you can name a genre, I’ve probably played it at least once! (except for RTS games, not a fan of those...)), so naturally my interests in the gamedev space are varied as well. I want to create as many games as I can, with as many different and intriguing aesthetics, stories, and designs as possible. If I had to narrow it down, I am particularly interested in level design, and creating fluid and fun movement options.

Within IGB120, I want to nail the basics of design and internalize concepts I'll need going forward in my career as a designer, and I also want to make some prototypes that show off my ideas and creativity, and are hopefully fun as well!

Look forward to more posts about a platformer prototype I’ve been working on soon!

[vi-r-gamedev]

Unit wrapup

And with that, IGB120 is completed! I've really enjoyed the unit, and have learnt a lot about designing. Getting to experiment with so many different games and practice coming up with ideas has been really fulfilling.

Don't leave this blog though! I still intend to use it going forward to post things i'm working on and towards. For example, i'm looking at participating in some game jams coming up, so keep an eye out for those!

[vi-r-gamedev]

Assignment 3 postmortem

I’ve already discussed a little of what changes I made to the prototype and why in the ‘playtesting and iteration’ post, so I won’t double up on that here. However, there’s always more to think about and discuss, so let’s get into it.

Genuinely, I am incredibly happy with how the prototype turned out. Feedback from playtesters was incredibly positive, and now that we have ironed out a couple of bugs the game is in a really good place.

If I was to go back and develop the prototype from the beginning again, I would switch a little of the assignment delegation within the team around. Setting each person to make 5 levels resulted in a slight disjoint between the levels. For example, horizontally moving platforms only appear in levels 6-10. Therefore, changing responsibilities could result in a more coherent product. Specifically, I would set one person to develop unique mechanics to go in the levels, and one person to collect these mechanics, and formulate all the levels around them. This could result in a more coherent final product.

As far as the design of the prototype goes, the only thing that I would change is have the intent of the game being a speed game from the very beginning. Although the game ended up working well as a speed game, it may have been even more fun and satisfying had this been in mind from the very beginning.

[vi-r-gamedev]

Interesting game mechanic discussion

As part of my studies in IGB120, I’ve been thinking a little bit more in depth than usual about games I’ve been playing. One thing I wanted to talk about is a super unique spin on the classic pokemon type chart from a game I played recently called Cassette Beasts.

Similar to pokemon, cassette beasts has monsters with types that interact with each other in particular ways. However, analysing their system of reward and punishment in the game is much more interesting than pokemon’s. Although pokemon’s classic “It’s super effective!” is nice to see, and the huge damage that can be output is a good reward, Cassette beasts has a popup in red text if a hit was effective, and in green if it wasn’t which helps communicate this difference using more effective means. Also, rather than only changing the damage, moves apply buffs and debuffs depending on if  they were not very effective, or super effective. Debuffing your enemy can debilitate them severely, while buffing them by using a bad choice of move can make it near impossible to take them down. This leads to situations where picking a weak move to hit your own team with could flip the game in your favour, which I found to be an extremely interesting design choice to put a spin on a classic game mechanic.

[vi-r-gamedev]

Running out of Time playtesting + iteration.

Coming back again with some notes from the playtesting sessions we’ve been recently holding. Going in, I was very satisfied with the quality of the prototype. Everyone had done great work designing the levels with the main mechanic of the echo in mind. The lines worked so that the Echo was present throughout the level, and all the levels flowed nicely. However, before playtesting began, I felt that the game was still missing something.

The movement was good, all the mechanics were implemented well (or so I thought), and the difficulty curve was good. But, once the player finished the final level, there was nothing rewarding the player for beating the game. Rewards are a core component of game design, obviously, and they make the player want to go back and play the game again and again.(Fullerton, 2018). So, I created a simple ending screen, congratulating the player on beating the game. In a full build, the player may be invested in the game’s story, and be rewarded with a satisfying conclusion cutscene, but for a prototype this is good enough.

Here's the end screen:

As part of this, since I allowed the player to reset to the menu, I included a timer that calculated how long players spent in levels, as an incentive for them to play again and try and record a better time.

So, now onto playtesting data. The testers we’re all naïve, which was good so we could get accurate, honest feedback for how the game felt to play for the first time. Also, the testers all enjoyed platforming games, so they fit the target demographic we were aiming for. Also they had varying levels of experience with games, so we could get a good breadth of data.

Immediately, a few issues were noted by the playtesters. The walljumping mechanic, which we as developers were comfortable using, was incredibly difficult for players to learn and use themselves, resulting in significant frustration with certain parts of the game.

It was noted by a few playtesters that the level intended to teach wall jumps did not require wall jumping to complete. To fix this, I redesigned the level to require the player to jump up between two walls to reach the key for the exit. This not only allowed the player to learn wall jumping in a safer environment where they were not excessively punished for failure, but also taught the key mechanic better, as one of the playtesters skipped using the key since they didn’t believe it to be important. These changes, combined with Ben reworking the wall jump coding to be more consistent, should alleviate frustrations.

Here's the reworked level before and after

Before:

After:

Luckily, beyond the frustration with wall jumping the testers really enjoyed the game. In particular three testers (the three most experienced with gaming) loved the speed run aspect, and played multiple times to try and complete the game as fast as possible. These testers all mentioned that being able to see a timer during the levels would be good. So, I implemented that. Also, deciding what information to communicate to the player is important. (Fullerton, 2018). I decided that the time should be communicated to the player, as there is no real reason to keep it secret only to reveal it at the end, and giving the player this info may cause them to engage deeper with the game.

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press

[vi-r-gamedev]

Assignment 3 Development

For the third assignment, I’ve teamed up with some classmates, and will be working on one of their games; Running out of Time. To introduce the game, It is a puzzle platformer, where the player encounters the ‘echo’ of their past self, which follows the path they’ve taken in previous levels.

To develop the prototype to a minimum level to playtest efficiently, we decided that the main focus would be in level design and creation, as the main mechanic of the echo depends heavily on the design of the levels and the relation to the previous level. Remaining conscious of the time required to play a significant enough portion of the game to effectively playtest, we decided to create a total of 15 levels, or 5 each. As each level is the size of one screen, maximum 2 scrolling horizontally, they are quite short, so we considered this to be a reasonable amount to develop.

To begin my development process, I brainstormed to come up with some mechanics to be implemented, which allow the game to remain varied, but still simple enough to develop. Since I have a team this time, I was able to come up with the slightly more complex concept of a wall jump and platforms which can move vertically, with the possibility of being desynced. It was my responsibility to code the moving platforms, which I was able to do rather easily with my knowledge of GDevelop object variables, and the inbuilt mathematics functions allowing for simple sine wave movement, with variables adjusting the amplitude of the wave and allowing for a platform offset.

Here's the code for that:

I was assigned the role of creating levels 11-15. To begin my process, I mapped out in photoshop the route the player would take through the level, including the position of any moving platforms, and ensuring the path overlapped with the previous levels’ in an interesting way to promote interaction with the main mechanic of the game. Following this, I simply built the levels in GDevelop, and played them to adjust for movement, jump distances, and to ensure they were beatable.

Here's one of the levels I made:

Also, since I was the member of the group with the most confidence in sprite editing/creation, I took on the role of artist for this project. The spritework my groupmate had used for the early prototype was effective, but lacking cohesion. In particular, they wanted to update the echo from a generic ghost into a more sinister reflection of the player. I took the player’s sprite, greyed it out to make it seem more like a ghoul, added bright orange eyes which stand out against the mainly grey background, and replaced its legs with a more ghostly trail to really communicate that detail. Additionally, I added an animation of red lines scrolling along the echo’s body, inspired by the green code lines used in the film The Matrix, to give it a touch of the futuristic, and to help it stand out even more on the screen. Given that I am not majorly involved in creating art usually, I think it turned out pretty good!

Here's the Echo sprite (not animated since uploading as a GIF gave me trouble, watch this space):

[vi-r-gamedev]

Sell Sheet and One Page

For the course, we were required to create a sell sheet, and a one page describing one of our prototypes. As it was possible that the prototype chosen would continue development, I had to choose something that I believed was a fun game, and possible to iterate upon further, so Scrapyard World was out of the question.

Ultimately, since it was down to Mecholution and DSMC, I decided to choose the game which I believed to be possible to represent better as an aesthetic, since DSMC was slightly more vague, and, not being an artist, Mecholution was easier to find suitable assets to commuincate the style in the sell sheet.

Unfortunately, choosing Mecholution (now known as Full Rewiring, updated during the creation of these documents), ended up being a slight mistake. One A3 page, dictating the technical requirements of the game was the required item to submit for this, and Full Rewiring, being designed around variety in abilities, enemies, and having a significant amount of player choice, had so much to detail that a full Game Design Document would be required. I did condense the information down to an A3, however it was quite vague in places, and didn't effectively communicate the ideas. Here's the One Page:

Clearly, the detailing is more on the side of design notes, rather than technical specifications, and it is frequently said "More than this will be present". This is bad for a One Page documuent, However I believe I created it to the best of my ability. Furthermore, the text boxes were selected to be in line with the aesthetic choice of billboards from the Sell Sheet, And this resulted in the readability of the page being sacrificed.

Here's the Sell Sheet:

I think I did a much better job with the Sell Sheet, as it gives a strong image of the Aesthetics of the game, and the core features.

[vi-r-gamedev]

Scrapyard World Postmortem

Scrapyard world is the first prototype of mine that I can confidently say has failed to clear the foundational bar of being a fun game.

During development, I was working mainly to create the system of memory to remember obstacles generated, so that the idea of playing through the levels in reverse could be realized. At the most base level, this idea isn’t bad, however there were many aspects that I used developing the prototype that simply didn’t work for this concept. A large one was the choice of engine, which created issues as discussed in the development post. Another was the use of random spawns. This created moments where playing in reverse was impossible due to the way that objects had been created while playing normally, causing frustration for the player.  I do believe the idea of venturing out into a space for a set time, then returning to a central location could work for a game, however this would be best utilized in a 3D environment with a prebuilt map, and a time pressure on the return to create a sense of urgency, and spark the players fiero.

One thing I would change about the development would be, as discussed, the engine used. However, within the constraints of GDevelop, the main thing I would change would be the movement. The system I developed felt slow and unresponsive, as the car took time to turn before moving to the left and right, and the inability to move up and down, as if accelerating and decelerating, felt illogical. This caused the game, which was conceived as a ‘racing’ game, to feel slow, the antithesis of the desired emotion for players.

Something to change about the design of the prototype, within the constraints of GDevelop as an engine, would be the types of obstacles that could spawn. As they were other vehicles using the road, they were essentially large rectangles to be avoided. This was boring, and caused the player to grow tired of the game after around a minute of playtime, as there was little to no variety. It also limited the ability to spawn obstacles frequently, as their size and shape caused significant issues in playability when more than sparsely populated. Therefore, creating other obstacles, such as winding passageways or faster, smaller obstacles would spice up the gameplay, and cause the player to be invested for longer.  

[vi-r-gamedev]

Scrapyard World Development Update

While developing Scrapyard World, I have been trying to push the variable system in GDevelop to work the way I require for the mapping system in the game. The main thing I have learned from this is an increased understanding of this system. The game otherwise is still incredibly simple, as learning about this system took most of the time I had.

With a bit more work put into the game, I have created a system which remembers the positions of obstacles which have spawned during the game by inserting them into an array. Overall, the system works, however it is clear that the concept was flawed at a base level, especially in attempts to develop in GDevelop. After a short amount of time, the game begins to take up significant computing resources as the array grows in size, and the only way to mitigate this is to decrease spawning rates to a level which results in significant loss of moment-to-moment gameplay.

I believe the idea did have merit, but GDevelop as an engine was wholly unable to realize the idea.

Additionally, creating this system took up so much of my time that the aesthetics of the game are entirely not present. However, this has shown that asset creation is by necessity a unimportant aspect when it comes to prototyping. I will cover this more in the Scrapyard World postmortem.

[vi-r-gamedev]

Scrapyard World - elevator pitch

Time for yet another pitch, for a top-down racing game.

In Scrapyard World, players take control of a group of scrappers living in a post-apocalyptic city. During the day, they must venture out into the depths of the city, searching for scrap to upgrade their vehicle, and eventually conquer their city.  However, as night falls, the dangers of the city come out, and the scrappers must hurry to return to their base. When they return, they map out the path they took that day, and prepare to venture further with the vehicle upgraded by the scrap they’ve collected. The game is like a mix between a less violent version of Mad Max, roguelike games such as Hades, and Maze Runner. It will utilize a day-night cycle, and an evolving map as the player explores more of the city.

The primary gameplay consists of players exploring the city and collecting scrap in their vehicle during the day, avoiding immobile obstacles such as piles of junk and buildings. They must also make choices of directions to continue in, which will be retracked once night comes. In the night, the player must remember the directions they went in, and return to their base while avoiding more dangerous obstacles.

The control scheme is incredibly simple, only requiring inputs for left and right movement, which will use ‘W’ and ‘D’ respectively, due to the simple nature of the top-down racing genre. In addition to this, the game will simply use the mouse and displayed buttons for menu navigation.

Some selling points of the game are:

Top-down racers are very simple to control, allowing new players to play easily, and simplifying a genre (roguelikes) that they may not have previously had access to.

Post-apocalyptic aesthetics allow for interesting artwork to be made, and are popular in gaming audiences.

The mapping dynamic is interesting and provides an additional layer of challenge to an otherwise overly simple genre.

Concept art:

Referenced:

Earl's Scrapyard. Retrieved from: https://i.pinimg.com/originals/60/f2/da/60f2dab7439e06aa3a26306c62cb54da.jpg

[vi-r-gamedev]

Asteroids Postmortem

Now with another prototype developed, its time to wrap up the posts on DSMC.

For this, the main design aspect I was thinking about was moment-to-moment gameplay. Asteroids as a concept is one of the oldest in gaming, so if DSMC felt too similar to it, it would likely grow boring very quickly, so the moment-to-moment gameplay, which the player is focusing on most often, needed to be different enough to feel fresh. With the inclusion of the different ships, I believe I accomplished this goal. They each feel fresh enough to distinguish DSMC from classic Asteroids, yet similar enough to be easy to play.

One thing I would change about developing the prototype would be to set up a universal control scheme. In creating the multiple ship types, I had to redevelop the control setup for each version of ship. This was incredibly time consuming and held me back from spending time developing other things. Creating a universal control system would not only help with that, but also clean up the code significantly.

If I had to change something about the design of the prototype, it would be the size of the asteroids. At the moment, it is a little too easy to avoid asteroids, and the mining sites, as the same size as the asteroids, don’t pose much of a challenge as environmental hazards. It is a small change, but even small changes can drastically affect the balance of game systems, so it would definitely help with this issue. If its not enough of a change, adjusting further can be done, and it is best to avoid throwing the system too far out of alignment. (Fullerton) Referenced:

 Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

[vi-r-gamedev]

DSMC Development Update

In GDevelop, working on DSMC has been really fulfilling!

I have used a free tileset I found on itch.io to help with the aesthetics a little bit, and this is what the prototype is looking like:

Most of what I have been trying to achieve is the basic functionality of the game, such as creating a working control scheme, and setting up the resource collection functionality. One thing I noticed while creating the prototype, is that in this early version of the game without any enemy NPCs, there is zero incentive for the player to actually shoot. This speaks to an underlying completeness issue, which would be fixed with the introduction of enemies, but may not need to be addressed in this prototype. However, I found that since resources could be collected just by setting up the mining sites and dodging asteroids in a separate area of the screen, the game got boring very quickly. Some kind of variety or evolution was needed. So, in a hotfix style update, I added the ability to gain resources by shooting asteroids. This meant that the player could leave the screen as is and gain score slowly, or be more active and gain score quickly.

However, another problem developed because of this. Due to the random spawn nature of the asteroids, the player could setup the mining sites on one side of the screen and shoot asteroids on the other. This was fixed by adding wraparound capabilities to both the bullets the player fires, and the player themselves. As well as causing missed shots to be possibly more impactful, this alleviated the issue of the player getting ‘lost’ outside of the bounds of the screen.

Overall, I am happy with my progress in creating with GDevelop, and have created a prototype that is fun, and ready to be iterated upon.

Referenced:

Ansimuz: Top-Down Assets Collection. Retrieved from: https://ansimuz.itch.io/patreons-top-down-collection

[vi-r-gamedev]

DSMC Pitch

Another pitch, this time for a game similar to the early Atari Asteroids games!

In Deep Space Mining Corp (DSMC), players are contracted to work for a mining corporation, setting up and protecting mining sites as they extract valuable resources from asteroids. They man various ships and aim to provide as many resources as possible to the corporation, amidst dangerous asteroid fields, assaults by the horrors of the void, and sabotage by other companies. The game is a mix of Deep Rock Galactic, and classic Atari Asteroids, combining the simple style of retro gaming with the appeal of defending points of interest and generating as much value as possible.

The primary gameplay consists of players selecting their ship, setting up the mining sites, and fighting off waves of enemies which attempt to kill the players and destroy their mining sites. The mining sites generate a set amount of resources over time, but also freeze a large asteroid in place, becoming an environmental hazard. The enemies which spawn will have similar types, but different target priorities in their AI. Alien beings will target players, while enemy corporations will target mining sites first. Learning this and defending their resources properly forms the core of the gameplay. Also, players can destroy mining sites themselves, so they will need to be precise with their battling.

As a challenge to myself, and partly also because the control scheme with the mouse felt clunky, I am designing for an Xbox one controller. Here is the primary control scheme:

Some selling points of this idea are:

The risk/reward factor in setting up mining sites, which create environmental hazards and cause the player to think about future actions, is compelling.

Simple controls are easy to understand, letting players pick up the game extremely quickly.

Similarities to retro asteroids games ensure players are familiar with the base mechanics, letting them learn the unique mechanics in DSMC easier.

Concept art:

Referenced:

Google Images: Asteroid Mining. Retrieved from https://scitechdaily.com/images/Asteroid-Mining-Concept.jpg

[vi-r-gamedev]

Platform Game Postmortem

Now that the creation of my platformer game prototype is done, its time to reflect on the design.

A big thing I was thinking about while designing was game balance. From playtesting and the concept of the game, I was confident that the core design of a fast-paced platformer with more reliance on special abilities was fun, so the main thing I wanted to test for was balance. This meant that I had to make sure that each ability was useful and relevant, and the drawback for leaving them unused was not too significant compared to the ability itself. In the prototype, this manifested in doing variable-based balancing (Fullerton) to ensure the basic movement abilities I had created were smooth and fit with the movement of the player. Also, since I only created a simple health drain for unused abilities, I had to make sure the damage per second was not too high to be unbearable, and not too low to ignore.

One thing I would change about the prototype is the UI. Having the lives/HP represented numerically, and the ability cooldowns represented graphically, made it difficult to tell at a glance what was happening. In a more fleshed out prototype I would represent HP graphically, with a bar representing the percentage of HP remaining. Also, there was no feedback on when an ability was left unused, making it difficult to play around. To display this, the UI would show when an ability is debuffing you by changing the sprites colour, and in a more final version of the game playing an animation.

Something to change about the design moving forward would be to give the player a way to damage enemies outside of abilities. It was frustrating to have no way to affect enemies, since the early prototype abilities were movement-based and not damaging.  Also, I want to design enemies with more of a presence than the simple ones present in the early prototype, and having a way to deal with these enemies even with a low damage ability set will be important. So, I would introduce a simple, low damage gun that the player can shoot at enemies with. This has the added benefit of introducing a reload mechanic – when the player is out of bullets in their weapon, they must immediately reload it, which locks them out of abilities for a short time. This would mean there is an additional layer of complexity and planning to using abilities, which was something the prototype was lacking.

Referenced:

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

[vi-r-gamedev]

Mecholution Dev post 1

Here’s my first development post for Mecholution!

Most of the development has been learning about the game engine I’m using; GDevelop 5, so I haven’t made a lot of progress on prototyping, but from here it should be much faster now I am comfy with the basics!

So far, I have a default tileset from the course setup to represent characters and elements, acting as placeholder for future aesthetics, and supplemented with a few things I created for the project. Heres what the current (very prototype) environment is looking like:

I have mostly tweaked the behaviour of the character so the movement feels fluid, and have been mainly working on giving them the first of their abilities – an uppercut that lifts them into the air, deals damage, and allows them to jump again once it is over.

So far, I have successfully coded in the movement of the uppercut, and its cooldown. Currently, this is 7 seconds, though as the game evolves, I will continue to tune this, alongside the number values of its associated forces for fairness, balance and overall fluidity, and to insure the internal system works as intended (Fullerton).  Also, I have elected that all skills (with some exceptions in future possibly) will start on cooldown, as the mechanic where if an ability is unused for too long the player is harmed could become frustrating if all abilities are off cooldown, and therefore unused, from the very beginning of each level. Additionally, I put my incredibly meagre artistic skills to use in creating the graphic representing the ability in the top right of the UI, as the game would be hindered, rather than helped by hiding information about the state of the system from the player (Fullerton).

Other things I have added are mostly simple platformer elements that are mostly built-in, and enemies that move side to side, and damage the player when they come into contact. Also, to ease frustration on taking damage, I programmed a simple timer that causes the player to be invulnerable for three seconds after taking damage, with a change in their characters' opacity to communicate this.

So far, this development experience has been invaluable in helping me grasp the foundations of the engine, and learning how to program abilities with cooldowns has been very useful as, spoiler alert, they may return in the near future.

Referenced:

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press.

[vi-r-gamedev]

Mecholution Pitch

Here's an elevator-ish pitch for the platform game I have been developing a prototype for!

In Mecholution (working title) you play as a disgruntled employee of a large company in a sci-fi/cyberpunk future who has been laid off as their role was replaced by AI. You set out on a vendetta against your ex-employer, a robotic mastermind, partially to prove humanity’s worth, and partially as simple revenge. However, to set yourself on equal footing with the robots opposing you, the player needs to customize themselves with various cybernetic abilities, but their compatibility is low, and the upgrades require continuous use to keep the brain melded with them. In this platformer which melds the challenging platforming levels of celeste with the continual upgrades, bosses, and unique abilities of a metroidvania title like Hollow Knight, players will take on the burden of resistance in a body entirely unsuited for it.

The primary gameplay will consist of players navigating through each of the levels, using their abilities to pass obstacles, defeat enemies, and ascend to the top of the corporate tower. Occasionally, they will encounter more challenging boss enemies which must be defeated to move on. Also, there is a secondary layer of strategy which comes from selecting which abilities the players want to equip and finding new ones to try out. The target audience will be existing fans of the cyberpunk aesthetic, as well as players of both platformer and metroidvania games. Additionally, the game may appeal to players of roguelike games, albeit less so.

This is my preliminary control scheme:

Some selling points of the idea are:

Interesting and dynamic movement systems will have a low skill floor for players to pick up the game, and a high skill ceiling for players to truly master the game.

Somewhat customizable character options let players play the game how it suits them.

Requiring repeated ability usage causes players to think in depth about the options they choose to take, and ensures no ability becomes stale or useless.