quick43

[quick43]

Assignment 3 Lightweaver Postmortem

Throughout this assignment, we iterated through the development and playtesting cycle as a group. To further understanding and adeptness at this process, here is a brief reflection on the assignment.

After the first wave of playtesting, lots of bugs and issues were found, as well as general dislike of the current control scheme. Changing this was extremely difficult and time consuming as a large amount of the code had to be completely rewritten. This could have been avoided by implementing a more intuitive design in the beginning, however at the time we were unaware of this.

The current prototype is significantly more functional than the initial one. Despite this, I feel implementing more animations all around would make the game look and feel significantly better. For example, player animations, background animations, animations for interacting with the environment, animations for the light beam and animations for the door. All of these would make the game more immersive and visually appealing. As well as this, one of our playtesters mentioned that certain animations would make the game more understandable.

Along this same vein, continuing production of original assets would ensure that the game looks cohesive and appealing. This is simply fixed with more time.

However, in its current state, Lightweaver is suitable for the submission of our group assignment, and development can continue of the game if our group desires.

[quick43]

Assignment 3 Lightweaver Playtesting

With a functional level of Lightweaver developed, our group had some naive playtesters from around university and accommodation give feedback on our mechanics so far.

The main consensus so far is that the controls are confusing and difficult, due to both poor functionality and lack of guidance. Despite this, all playtesters found the game mechanics interesting and enjoyable.

Numerous bugs were found including the jump control not working, as well as the player was able to walk off the edge of the map. These are both easily fixable, by fixing the jump control code and adding barriers on each side of the level.

More problematic bugs with the game include the light beam seems to disconnect from the main crystal when the player moves the mirror under it. I am unsure what specifically causes this, however I assume it has to do with the dimensions and implementation of the light sprite, as it works fine with a blank sprite.

Additionally, the player can walk away with the mirror and have the light continue to reflect off of it. This was fixed in the initial design by changing the collider of the mirror, so this can be done again in this version of the game.

Despite this, most playtesters really enjoyed the pixel art style. The differing resolutions of the assets was pointed out, however this will be improved as we develop more original assets.

Overall, the main problems with the game right now are repairable and will be improved as development continues.

[quick43]

Assignment 3 Lightweaver Development Post

For our third assignment in IGB120, we are developing a fellow students Platformer design from earlier in the Semester.

Named Lightweaver, this platformer consists of a miner exploring a set of mysterious caves. These caves are filled with strange crystals that emit concentrated light. He must reflect this light around the room to complete puzzles and open doors.

As I have been appointed the main task of code functionality, my main focus has been on implementing a system of light reflecting and transformation that feels satisfying, intuitive, and enjoyable.

Immediately I had the idea to have the light beam stretch until it reaches a solid object, such as the ground, a wall, or a mirror. This worked initially, however it took some time before the light looked smooth when it hit a surface. We ended up having the light exist behind the platforms to simulate the light not traveling any further than them.

The gameplay is currently functional, however there are some inconsistencies, such as the light beam moves slightly from left to right when the player moves the mirror through it. As well as this, The player does not have in depth movement animations yet due to time constraints of our artist.

It has been interesting trying to combine the programming, sounds, art and level layouts all together after making them all individually. However it has worked as we have used the Canvas group files to transfer all of our parts. We then teamed up to clean up all of the inconsistencies in our designs.

Despite this, the gameplay is functional and ready for playtesting.

[quick43]

Rushline Playtesting and Postmortem

The initial prototype of Rushline has been platested. The general player consensus is very postive so far.

All 4 playtesters have really enjoyed the current gameplay and inital style.

A main comment was that despite the enjoyment of the game, most of the gameplay felt repetitive and unrewarding. This is mainly due to only a single level being develop for this stage of development. However, this got me thinking about possibly scrapping the idea of levels and introducing a more high score, single run style of play. I am currently unsure what players will find more rewarding, so making this new system and playtesting it could be helpful.

Also, later in development it came to my attention that the way I had made the player interact with obstruction on the road was quite jarring, as the player would slow down but still drive through them. This could be made cleaner by having an animation of the obstructions being destroyed when the player hits them. This would make the game smoother and add more depth into the visuals.

The playtesters also commented on the lack of animations for both the player vehicle and the traffic, since the game is top-down. This could be fixed by implementing smaller, unrelated animations like headlights, sirens, and vehicle turning.

Overall, Rushline is an enjoyable prototype to continue development on.

[quick43]

Rushline Development Post

During the development of Rushline using Gdevelop, many challenges have been found due to the software's functionality.

I have been trying to achieve a single working level to show that these systems are possible, and that the gameplay is enjoyable. Making a basic, lane-by-lane racing game using the workshop materials from IGB120 and editing it to fit the desired gameplay has been the easiest approach so far. However, the Workshop prototype works specifically off of the dimensions of the assets used, so importing new assets means that a majority of the code must be rewritten, and variables must be adjusted.

It has been interesting utilising the "distance from police" variable, as it is adjusted by both scene timers as well as player interactions with scene objects. I assumed this would cause some issues or bugs, however so far none have become apparent.

While making the gameplay, I had the idea of a speed boost that the player could charge up by not hitting any obstacles for a certain amount of time. However I will omit this from the prototype for now.

[quick43]

Rushline Elevator Pitch

Rushline is a futuristic, dystopian racing game where the player must weave through dense traffic to escape their oppressive pursuers.

The main gameplay consists of the player moving their vehicle side to side through traffic until they escape their pursuer. When players hit obstacles or other vehicles, they slow down. If they slow down to much, they are caught and lose the game. Once enough distance has been made between the player and their pursuer, the player wins the level.

The roads of this world are unkempt and damaged, making driving difficult. However, the player's less than legal vehicle has the capacity to outspeed the law enforcement, with enough skillful control.

The game will be in a cyberpunk, dystopian style, consisting of pixel art reminiscent of Hotline Miami. The game will blend retro graphics with modern, smooth gameplay for a nostalgic yet satisfying experience.

This game is aimed at two main audiences. One being those who wish to best all levels, and reach new high scores. The other being those drawn to the aesthetic and style of the game, whether through interest in the world, or the nostalgia brought by its artstyle.

Contact Info:

Kody Kent-Ford

n11977931

kodfishhp21@yahoo.com

[quick43]

Kaleidostrike Playtesting and Reflection

After having a few people playtest the rudimentary model of Kaleidostrike, the players were mostly pleased with the gameplay so far. They enjoyed the colorful and clean feel to the game, as well as the simple controls. However, they found initially starting the game confusing. A simple tutorial or controls screen cook fix this quickly.

The simple UI and gameplay meant that even people who had not played many video games enjoyed playtesting this game.

Those with more experience suggested that instead of having the player follow the mouse, have WASD movement controls instead. This would fix the strange behavior of the player when the mouse is not moved, as well as make it easier for the player to avoid shapes.

Since this was a very rudimentary version of the game, there are many more features to be added, such as more abilities, and a slight increase in difficulty as the player gains more points. Also, new sprites could be added to make the game feel more unique and alive.

It is probably a good idea to go back and change how the beam attack works, as it currently moves as the player moves, which means that if the player turns rapidly as they use the attack, they can clear about half of the screen of shapes. Making it a static sprite that exists for a short time would be more suitable.

Overall, there is a lot more development and playtesting to be done on Kaleidostrike, but the current outlook is promising.

[quick43]

Kaleidostrike Development Progress

As seen in the video, the gameplay of Kaleidostrike is currently fully functional. Still tweaking the fire rate of the player to feel more balanced.

Also yet to implement any complex animations to both the player and the shapes. Once these animations and effects are implemented, the gameplay will appear a lot smoother and more satisfying.

For now, the game keeps track of the player's high score, and displays the top value. A system could be implemented to display a leaderboard of the top scores by a certain player.

The beam ability also functions well, however, I have been trying to make a small, area of effect attack that shoots around the player. This is proving difficult as the original idea was to have bullets spawn at set angles from the player. For some reason, the bullets only shoot to the top left of the player character, and the rest stay still. Still not sure as to why this is happening. Possibly will try a new sprite similar to the beam.

The beam was made as a sprite that is invisible in front of the player the whole time, and is unhid for a small duration when the player uses it. Getting to this point took a fair amount of time, and eventually the input of a friend to get it working.

[quick43]

Kaleidostrike Elevator Pitch

Kaleidostrike is a single-player, top-down shooter game where the player collects points and unlocks new skills by destroying colorful geometric shapes.

Modified sprites supplied in our workshops will be used to represent the shapes. For example:

Additionally, the player sprite from those workshops will be used for now.

The game will play as the player character follows the user's mouse around the screen. Left click will be used as a basic weapon attack, and as the player unlocks more abilities, right click, middle mouse button, space, and other keys will be used.

Kaleidostrike aims to have satisfying and stimulating graphics that encourage the player to keep playing. The main replayability comes from players reaching new high scores and developing strategies that will help them reach them.

Every 1000 points or so, the player will unlock a new ability that opens up new pathways to play the game and reach high scores. These abilities will each function differently to keep the gameplay interesting.

Ideally, the gameplay will feel fair and rewarding, with the difficulty coming from the time survived by the player. Their high score will then be displayed on the start screen as a sense of achievement.

Contact Info:

Kody Kent-Ford

n11977931

kodfishhp21@yahoo.com

[quick43]

Civitisludge Platformer Reflection

A rudimentary gameplay example for Civitisludge was completed, and several players tested and responded to the gameplay. The most common consensus was that while the rudimentary gameplay worked, and the theme of the game was interesting, the current state of the game was not enjoyable to play. There was no way to track the number of enemies the player has defeated before the end screen. Additionally, there are currently no progression elements as this demo was to demonstrate the combat elements at their core. It was also noted that players found the attacks between both the player and the enemies unresponsive and difficult to understand.

These are all improvements that can be implemented in further development of the game, to ensure that it is enjoyable. A kill tracker can be added to the gameplay to keep the player invested. Several forms of progression can be added, such as enemies dropping healing items, and the player getting stronger through higher stats and new skills. This would come in tandem with adding a system that allows the enemies to get stronger as you progress. And finally, to allow the combat to feel more responsive, a stun to enemies and the player after they are hit can be added, as well as possible animation changes to confirm that an attack was landed.

Overall, in its current state, Civitisludge is not a fun or complex game at all. However, through further development and playtesting, it can be improved.

[quick43]

Civitisludge Rudimentary Gameplay

The gameplay of Civitisludge now functions in a very early way. There are basic movement, attack and enemy systems, as well as a time tracker as a goal for players at this moment. All of these features still require further development, however in this state it can finally begin playtesting. This will allow features to be developed further in a way that players find enjoyable, while also tweaking any currents aspects of the game that are unenjoyable.

[quick43]

Civitisludge Sprites

I have found enough open use sprites online for this stage of Civitisludge's development.

This rogue sprite and animations by @calciumtrice functions well as the Player Character, as he resembles a post-apocalyptic survivor.

This seamless cityscape background made by TokyoGeisha will function as the backdrop for the starting levels.

This sprite sheet by tebruno99 will be used for several parts of the game. The Platforms in the bottom left function well for the color scheme and themes of the game. Additionally, the boxes in the bottom right will be used of the borders of the level.

This Enemy sprite sheet by Stephen Challener (Redshrike) functions well as the main enemy for Civitisludge. Fitting into the sludge-like, post-apocalyptic themes of the game.

There also some other sprites that i have found that I am yet to decide on the use of:

These face sprites by Blarumyrran (blarumyrran@gmail.com) could possibly be used for the player icon/enemy icon. Honestly I just think they are cool and want to find a way to integrate them into Civitisludge.

These backgrounds, by surt and ansimuz respectively, could also function well for some later levels in the game.

And finally, this cat sprite by Shepardskin (https://twitter.com/Shepardskin) could function well as a recurring npc or a secret that the player can find.

[quick43]

GDevelop Learning Progress

As a part of IGB120 and Civitisludge's development, I have been learning the free games development software GDevelop. Coming from softwares such as Unreal Engine 5 and Unity, its has been fairly simple to pick up on GDevelop's functionality. Some main hurdles in my learning was the built in Piskel sprite editor, which has been extremely helpful when editing sprites on the go.

As well as this, learning how GDevelop handles collisions and hitboxes for both characters and platforms has been very interesting. The almost "set and forget" mentality with the behaviors system has streamlined the process of making a rudimentary level for Civitisludge.

[quick43]

First Assignment Elevator Pitch

Game Name: Civitasludge

Civitasludge is a basic platformer with melee style combat. The aim of the game is to defeat all enemies as fast as possible, while possibly discovering some of the secrets hidden within the game. Civitasludge will follow a post apocalyptic industrial theme with a pixel art style.

These images are the main source of inspiration and theme for Civitasludge.

Civitasludge will be a 2D platformer, and follow the most common control scheme for that genre of game. A and D will act as movement from left to right. Space will allow the player to jump, and left click will act as an attack button. More controls may be added as the idea of Civitasludge grows further, such as E allowing the player to interact with parts of the environment.

Civitasludge's main features that allow it to stand out from other games include its theme and world, secrets hidden in the environment, and the smooth platformer gameplay.

The theme and world will be portrayed both through the art and graphics of the game itself, as well as secrets that are hidden within the environment. These Secrets will give the player more insight into the world they are currently experiencing, and the events that have led to the gameplay they are currently experiencing. And finally, the gameplay itself aims to be smooth and satisfying, blending the combat and movement in a way that keeps the player engaged.

More posts will be made regarding Civitasludge's development.

Contact Info:

Name: Kody Kent-Ford

Student Number: n11977931

Email: n11977931@qut.edu.au