Week 5a - Development: Unicorns Rage!
This week I set out a number of large tasks to bring this game into fruition and meet as close as possible to my overall vision. Being that the design sprint challenge 2 is based on asteroids, I really wanted to play on the style and twist the concept.
Now that I have developed a greater understanding of GDevelop and its events system, I set forth newer challenges in comparison to the last design challenge;
Global Variables: Health, Mana, Level Timers, High Scores
Character Selections: Choice of coloured Unicorns
Scenes: Title, Character Select, Win/Lose, HighScore, 3 Levels
Mechanic: Rotations Without Gravity to Recharge Mana
Mechanic: Different Moves
Dynamic Screen: Destroyed Planet with Partices and Debris Loop
Sounds: Self Voiced Effects for Spawns, Attacks and Enemy
Mechanic: Random Enemy Spawner
Mechanic: Multi-Directional Player Movement
To establish a playtestable game I encountered an array of problems. Learning from my previous experiences with the last challenge, I didn’t move on to the next challenge until I had a solution for what I was presently working on. At the very minimum, almost every mechanic I introduced was solely playtested 20 times, some a lot more so.
Mechanic: Multi-Directional Player Movement
The overall goal for this game was that the player would rotate in different directions around asteroids and attack enemies while spinning. Then as another asteroid would move closer by force, the player could jump to the other asteroid.
After at least 50 playtests and a multitude if different event condition structures I found that for every degree the player rotated around an asteroid, of any direction, the move which would be set at a certain point of a sprite, accross any animation or frame, would start 2 degrees behind the intended point and continue to start further behind for every additional degree the player rotated.
After countless hours of searching the internet and many feeble attempts to rectify this, changing points, conditions, instances, etc, I discovered that, unfortunately Gdevelop is limited in its point system and there wasn’t a solid way around this.
To have the moves with decent effect, I had to introduce multi directional movement of the player. However, I did not scrap the idea of rotating around the asteroids, I used it in a different and unique way.
I accomplished the multi directional movement by simply adding the multi directional movement behaviour to the player.
The challenge with this particular mechanic was directional. Initially, I created a rainbow object to fire only once while rotating around asteroids, as mentioned above, unfortunately it was not possible and a lot of time was lost to attempting to fix this.
Once I had decided to move forward with a different idea, it was easy enough to create a particle attack in any direction and angled correctly to player angle and direction.
The challenge that I faced later down the track was changing the particle colours to link to the player selected unicorn as I intended to have the particle effects match the colour of the player.
I created the basis of the moveset for one player and toward the end of production, duplicated the effects and scenes and linked the correct effects to player colour.
Global Variables: Health, Mana, Level Timers, High Scores
I had only used variables based on objects prior to this design sprint. Global variablkes were easy enough to traverse, however, in my rush I duplicated instances but did not chage the string conditions correctly, resulting in health being affected for a mana altering instance for example.
I combed the events page for each scene intricately to double check each condition and instance aligned as intended. After many play through tests I had the system working as expected.
Character Selections: Choice of coloured Unicorns
I left this particular inclusiomn until the very end of production. The reason being, I felt that by creating the game with the basic player first, I could replicate the scenes and change the player based on character.
Because I chose to have differing move colours, this resulted in having to comb through a long events page for my first character and ensuring I changed the events to meet the character of choice, ie collisions, particles, behind the scenes objects, forces, etc.
I also duplicated every scene and added the colour behind the name then playtested through each colour to ensure it all linked up correctly and so I could identify sections I missed.
A number of hours were spent editing the inital sprite to be a basic white, so that each following character frame was easier to paintbucket all with the desired hex colour. In total I edited 80 frames then duplicated in the root file path for each coloured player. Days were spent on this, shout out to the animaters yet again! hard hard work.
To save time, after doing one player colour, I thought “maybe I could do ctrl-F to find and replace each item”, to my surprise, this is a feature in Gdevelop, which shaved hours of my production! Once the first round of colours were done, I simply had to ctrl-F “pink” (example) and replace with “Blue” and every event updated instantly with no error. I still double checked for my own sanity!
Scenes: Title, Character Select, Win/Lose, HighScore, 3 Levels
Creating multiple scenes to link the players selection.
Due to leaving the player choice to last, I sillyly did not consider how many scenes I would end up having to make. I believe final count was 37, drastically increasing the size of the game and making, in actuality, 6 individual games.
Rather than delete scenes and comnb back through all events at the end of production (for a tenth time each page, minimum), Ive noted that I should instead create the sprites, animations, points etc first, then upon level design use the built in “OR” condition for collisions such as “If Enemy is collision with, BlueMove or RedMove or YellowMove etc - do 10+ score, delete enemy, etc”.
Then upon beginning of the scene I could have used global variables to indicate which player colour was selected and created the correct player upon startup of each level based on the Global Variable.
This method could drastically reduce the amount of scenes and events required and I have definitely learnt my lesson.
Mechanic: Rotations Without Gravity to Recharge Mana
Since scrapping the intial movement system, I wanted to keep the concept of the unicorn rotating around an asteroid as if caught by gravity and in certain directions I wanted to see the unicorn change its z order to give the effect the game is 3d, so moving in front and behind the asteroid upon rotation.
This was one of the hardest tasks for this design sprint.
Gravity became an issue and upon removing it, it affected other asteroids, resulting in having to revisit all asteroids again.
Rotations, flipping the sprite became a series of issues for all other coding, resulting in again, revisiting all other completed areas to double check where I had created problems. I also struggled with having the unicorn perform a perfect circle around the asteroid, resulting in oval rotations.
Z Layering, finding a simple way to alter the layer, using variables and hidden sprites this was accomplished, but I had to move the objects out of screen as hidden objects still created their effect on the player even if they werent on the asteroid, so moving them out of screen and back each time the player was on a specific asteroid as to not collide during normal play.
Firstly, I created a perfect circle on screen, had the asteroid and circle move with eachother regardless of force, added a “Tip” point on the circle and had the circle rotate in a direction at a normal speed. I then used variables to determine when the player was on which asteroid, example being that if RShift was held down when at asteroid one, the player variable “Asteroid” changed its string to “One” when the variable “Asteroid” was set to “One” it then triggered the player to move to the CircleOne point “Tip” and rotate with the circle around the asteroid. This initially worked, though the player would circle the asteroid in an oval shape.
I revisited the player points for all animations and found the middle axis at the very base of each animation and moved the “Center” and “Origin” points to that location. I “showed” the circle at the start of screen and tested the player movement, it worked perfectly!
Some asteroids had to also trigger which animation, this way the player would be facing the correct direction the background circle was rotating in. Forces woud lag or glitch the player if they were going to fast round the circle, this was easily fixed by slowing down the rotation and asteroid forces.
Though this was a difficult feat, I managed to create four different asteroid rotations with player interactivity!
Mechanic: Different Moves
The main challenge with the different moves was bringing my inital vision to life. Ie the colour scheme based on player and the “Bane of The Horn” move, which I wanted to explode from the player “Center” point outward in 360 degrees. I found this effect worked as intended but when enemies collided with the particles the collision events would not trigger. I later found that the reason being was that they needed to collided with the actual sprite object, not just the particles.
To combat the collision problem above, I decided to add another hidden rotating circle behind the player that moved as the player moved. Then creating the “Bane of The Horn” move at the player circle point “Tip” this created distance between the player and the object and it rotated swiftly around the player, meaning that collisions were extended around the player and hitting their mark.
Dynamic Screen: Destroyed Planet with Partices and Debris Loop
Firstly, the planet image was a challenge to edit with piskel, this tooka lot of time loading between edits, even when I attempted to use the paint all bucket to remove the white (I painted in a seperate program) as to limit the area I had to erase. Once that was surpassed I wanted to have the planet in the background getting smaller each level, but also displaying a fire effect, like it was burning from the core.
Lastly, I wanted to have a rotating loop of debris of sprites from my previous design sprint, as if to say the last game was on the same planet and the unicorn destroyed it. Though the setup of the debris loop took time, once filled with sprites I felt there were too many gaps between objects.
The debris loop took time, creating multiple points on a large circle and many object sprites, then the event conditions to move them to those points at the start of the scene. This worked, leaving gaps between these objects as they rotated around the circle and rotated themselves as they looped. My solution to this was to add a textured particle using the asteroid sprite and adding it to each point as well, this created an asteroid field like effect as the circle rotated.
Though the debris loop is a background element, Im really proud of how it turned out.
Sounds: Self Voiced Effects for Spawns, Attacks and Enemy
I wanted to play with the idea of including sounds this time around as my last design challenge I didnt.
I am not exactly equipped with a sound studio so my laptop microphone was the way to go. I took my grunts and typical frustration sounds while developing the game and hitting roadblocks and utilised them as enemy spawning sounds.
I also created little sounds for player attacks. Though these oddly when converted, became robotic on level 3.
I will need to revisit the robotic sounds and rerecord.
Mechanic: Random Enemy Spawner
The sprites I opted to use for this game I acknowledge Craftpix.net and gamerart2d.com as my main sources.
There wasn’t really too much of a challenge establishing a random spawner for each individual enemy I incorporated into the game. The challenge ensued more in creating an enemy move while rotating and from a distance.
I tackled this obstacle by playtesting through many possibilities. I ended up settling on an “Elf” enemy move that deducts mana from the player when the elf is facing the player in its rotation and force, shooting a particle effect toward the player.
I added a hidden object in the center of each level so when enemies collided with the border, they were forced back toward that object and so on.
This game brought a multitude of challenges, I eventually found solutions or new ways to incorporate my intial vision without sacrificing too much.
The game is not exactly perfect, but I am very proud of what I have produced. The above is only some of the many challenges and solutions I had with the development of Unicorns Rage, however the aforementioned is the bigger of the tasks and learnings during this design sprint!
Next, feedback and playtesting!
https://www.gameart2d.com/freebies.html
https://craftpix.net/freebies/
Unicorns Rage! Playtest Link
This link will take a while to load, once loaded it operates fine :)
https://games.gdevelop-app.com/game-de5f335c-4ad8-4256-ad78-03999ce704c7/index.html
