This week I have been following the tutorial provided by trying to get my asteroids to randomly spawn around the designated screen space and my player to move around and shoot the asteroids. Once I completed my prototype I tried to import a maze using the platformer sprites. However, the design doesn't feel very much like the game I had envisioned it. It feels too simple and unsatisfying.

In order to make the game feel more satisfying and smoother, I decided to go with a design style that fitted the artwork of the Cool Maths Game design "Worlds Hardest Game", which I felt would make the game feel smoother, and more entertaining for the competitive type players.

However, I wanted my game to be even more challenging and exciting by adding bonuses and more mechanics.

Key features I have imagined implementing include:

Powerups:

Rapid fire

Multishot

Invincibility

Speed Boost

Enemies:

Static

Moving (different speeds)

Enemies that shoot

Vacuums in space, that suck the player in

Each enemy type will be different in colour

Customisation:

Different spaceship designs for the character

Different coloured bullets

Different backgrounds

In each feature, I want to use a pixelated design style, that will fit an arcade-type asteroid game. This will elevate the smoothness of the game, and actually make it feel more natural and exciting. With the addition of competition by making the game frustrating.

First of all, I'm not a hardcore Asteroid player. I don't understand the meaning of 'score' to the player. I still think it was because of the poor performance of the machine at the time, which did not bring positive feedback to the player on the screen. This is a "forced design" by game designers.

This is why we can see more and more AAA games stop using this design, so I want to delete this meaningless design.

For both the spaceship and the meteorite, I used the simple physics system of Gdevelop 5, so that the spaceship or the meteorite can directly collide with each other, which is more realistic.

For the design of large/medium/small meteorites, when the bullet of the spaceship shoots the large meteorite, the large meteorite will split into two medium meteorites instead of disappearing directly, which will make players feel more rationalized.

I set a range outside the game scene, if the ship flies outside it will lose a life.

I ended up going with my original asteroids game idea, involving Zeus fighting the Titans. I am thinking of naming it Titan bolt. It’s hard though as there are so many mythological based games so I have to do something a little original. So I set about to make a number of assets on the pixel creation software Aesprite. I took a course on Pixel art on Udemy so I am hoping it comes in handy for this. I have the movement, lives counter and collisions sorted for the game so really I just need to create the various animations so that I can depict the theme I am going for. I am setting out to make: -Zeus riding a cloud from various angles -Changing the bullet to a thunderbolt for Zeus to throw -Make some Titans for Zeus to fight against. -If I have time a background of Mount Olympus.

FUNCTIONALITY!! That has been the theme for me this week. My asteroid game has a key mechanic : Limiting the range which it can fire. I wanted to have the ability to fire wherever the mouse clicks, but only at a maximum range of 300 from the player. This wasn’t quite as simple as i had hoped.... Before I could move onto sprites, movement, collisions or anything that would make the game a game, I needed to have this core mechanic down pat.

I laid down the foundation for the mechanic and made my sprite follow wherever my mouse was. I then attached a sprite onto my mouse which showed a splash area of effect gif I made to show where the projectile would land. Now for the tricky part, adding some structure to it. I did this with maths. My favourite... All those times in high school that I swore I’d never need Sine, Cosine and Tan... Well guess what Mrs Murray, you were right.

As demonstrated in my diagram below, I used triangles in order to calculate the position that the area of effect sprite would stop in order to remain inline with the mouse but at a distance of 300 from the sprite.

I won’t bore you with all the mathematic details but essentially you can work out  Θ through using D, XL and YL. Then with  Θ and H  you can work out x and y and then take into account the sprite distance from the origin. The method of whether you use cosine or sine changes based on which quadrant the mouse is in from the fish. In this example it is below and to the right of the fish so I would use acos and add the values. ( See second reference picture below )

After about 4 days of gruelling work and bugs and restarting my theory about 10 times I finally had a working prototype! The splash effect sprite would stop at a distance of 300 from the player and it was inline with the mouse. I added code for the bullet to travel to this point and destroy any ships along the way.

I’m definitely glad that I followed Fullerton’s advice and focused on my functionality before all else because the amount of times that I flipped my desk and restarted was insane. Once I had my functionality down pat, it was easy to start focusing on completeness and balance. I put together a small shark sprite animation and a cannonball to help give the game the theme I was after. Finally I continued testing and playing around with balancing the game. After reading chapter 10 of the Fullerton’s book, I realised how important balancing was. Initially my shark moved too fast, fired cannonballs too far and at too fast a rate. This made it almost impossible to be killed and the game way too easy, players were not thinking about their shots and just firing at will, making my primary mechanic negligible.

 In response I lowered the range and lowered the speed of both the cannonball and the shark. I was finally happy when the game met the goals I set for my player experience; it was of the scope and complexity I envisioned and all the elements were working together. Players were trying to setup combinations of sinking ships and choosing the best placements for their cannonballs.

Here is a short video demonstrating my working prototype :)

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

For this week I created my prototype 2D asteroid shooter game. I followed the tutorial guide and I was able to replicate and create my own version of the game in Gdevelop. 

I was able to successfully implement a ranged attacking system via a shooting system where the player can shoot bullets at incoming asteroids. The asteroids will kill the player if the player is touched and then will be transported to a game over screen. A life system was also implemented into the game that allows the player to take 10 hits before taking them to the game over screen. 

What have you been trying to achieve in GDevelop?

This week during my asteroids' development, I have been trying to achieve having a successful lives and a pointing system. These two factors contribute the most to the collecting and dodging mechanics within my game pitch.

What was something you learned?

Something I learnt this week whilst working on my pitch was how to implement a health/point system, eliminate objects after a collusion with another object, how to resize sprites/hit-boxes and implementing gifs into Gdevelop. I have also learned PUT IN DYNAMICS EG FEIRO AND BLUH BLUH

Showcasing Design Ideas & Concepts From/Inspired by Readings + Thoughts on Readings

The design ideas and concepts from or inspired by readings include considering the foundation and structure topics from chapter 10 (Fullerton, T, 2018). Whilst I was brainstorming for my pitch and also executing it, I was thinking a lot about the foundation and if the bare mechanics would excite engaging gameplay. Much like my platformer pitch, I thought a lot about if my main core mechanic was intriguing enough to be entertaining without being complicated, as I know I do not have a lot of time to implement it into the prototype base. I also thought a lot about the structure of my game and what the player would expect the layout or features would be based on other games like it. As a result, I put the point count in the top left corner like many other games and had a 'game over' screen when the player had lost all of their points.

Sources

This weeks blog post is about the development of the asteroids game which I conceptualized in last weeks post.

Development posts

·         What have you been trying to achieve in GDevelop?

I am still trying to learn how to use GDevelop so during this exercise I have set a goal of developing a cleaner, more functional game than my previous platformer. I wish to make use of more features in GDevelop and have a more artistic approach to the sprites I use.

·         What was something you learned?

I learned how to make use of more movement and combat features. The shoot feature is pre-defined in the GDevelop software and this was a main mechanic in my game. Through development I have gained a better understanding on how to program enemies with a focus on movement and combat.

·         Showcasing design ideas and concepts from/inspired by readings

Part 2, chapter 6 of the reading introduces conceptualization. I used the tips on insight, evaluation and elaboration to guide my concept from last weeks blog post into fruition through development. This reading helped me get my thoughts and ideas in order so I could focus on the development aspect of this game.

·         Thoughts on readings and how they apply to what you’ve been making