Development Blog (for IGB220) @stephenliuassignment - Tumblr Blog

WEEK 13 Postmortem

After participating in the Halloween spooky playtesting in week 2, I received a lot of feedback. However, I made only a few improvements because I didn't have much time; I still had to complete other assignments. The four weeks of development experience have given me valuable insights. Firstly, I am grateful that I knew what I wanted to do by week 9 because I noticed that some groups were still in the discussion phase by week 10, which would inevitably compress their programming time. I'm also pleased that I was able to complete the main development of the game and conduct playtests at week 11 because I knew that designing a high-quality game requires multiple iterations, and playtesting is essential for that, and the earlier, the better.

Among all the testing feedback, one comment stands out: two people suggested shortening the length of the player's laser (in weeks 10 and 11). Generally, players tend to lean towards offense rather than defense. (This is also why I designed multiple weapons to fire simultaneously in this game.) Players tend to want more powerful weapons, and I thought a longer laser would look more powerful and should meet their needs. However, players complained that the "laser is too long." I don't remember why I didn't ask them for further clarification, but from subsequent feedback, I speculate it may be because they couldn't see the position of the cursor clearly. So I reduced the visibility of the player's laser and replaced the cursor with a much larger crosshair. After these changes, no players complained about the length of the laser.

Another interesting observation is that players really prefer to go on the offensive. Even if they get killed, they are more likely to attribute it to insufficient firepower rather than lack of defense. I wasn't entirely unaware of this phenomenon; I've played or learned about some games that emphasize offense, such as Blade & Soul and Assassin's Creed Mirage, where the variety of weapons and combat items far exceeds that of armour. But witnessing players' extreme behaviour in Space Marauder still left a strong impression on me. Most players readily choose Burst over Shield, and for the 2ndary Turret, Plasma is the choice of most players because it has the highest damage, although it's only for single-shot damage, and players don't calculate DPS based on fire rate. I think the phenomenon of "players really like to go on the offensive" may guide me in designing future games, even though I personally enjoy survival games and prioritize defense. Maybe it's a good design to label a weapon with a prominent DPS value for the players like Diablo 3 and 4 did.

(BTW, as a designer, shouldn't we prioritize calculating DPS when evaluating a weapon rather than just looking at its raw damage?)

As for the overall project development process, even though I've been enthusiastic throughout, it seems that my teammates don't share the same enthusiasm. This phenomenon is not unique to IGB220; it has occurred in other courses as well, and unfortunately, I'm also one of the "unenthusiastic team members" in other assignments. A long time ago, someone told me that playing games and making games are very different, and now I truly feel that. I used to think that students who chose this course were all people who loved making games, but now it seems that many people just enjoy playing and don't really like making games.

I've heard some rumours about the capstone projects, and it seems that there are more projects focused on creating software rather than games. This makes me a bit uneasy.

The game can be played on gd.games:

Play Space Marauder on gd.games, a game created with GDevelop, the free and easy game-making app.

#postmortem

WEEK 12 Iteration & Changes

I received a lot of valuable feedback from the playtest, and this week's work is to improve the game:

Moved the materials dropped by enemies to the top right corner of the screen instead of the player's ship, hoping to make the battlefield clearer.

Enlarged the enemy missiles to 2x to make them more visible to players and easier to shoot down. Slightly increased the speed of enemy missiles, which were too slow before.

Set the default Side Secondary Turret to a 20mm MG (previously a 40mm Gun) to help players deal with enemy missiles.

Reduced the visibility of the player's laser to make it less likely to obstruct the crosshair.

Replaced the player's crosshair with a larger one.

Improved the usability of the shipyard interface and added descriptions for upgrade information.

Both the player and enemies briefly turn red when damaged, using adjustments and outlines from the effects.

Adjusted the channels for various sound effects to prevent them from easily overlapping and suddenly increasing in volume.

Implemented armor for the player and enemies, where the damage received by the target is now calculated as Attack - Armor. This helps balance different weapons. Due to the addition of armor, enemy HP has been moderately reduced by about 1/3.

Designed specific score rules for boss battles: Defeating a boss earns you 50,000 points, but this score decreases by 300 every second. This is done to prevent players from deliberately delaying during boss battles to kill more soldiers for a higher score.

Redesigned the Boss's laser cannon:

During the targeting phase, the laser cannon will aim slowly in the player's direction instead of locking directly onto the player.

Reduced the targeting time to 1 second because the long targeting time made players think they couldn't escape.

Increased the visibility of the laser cannon's aiming line during the charging phase to make it clearer.

Fixed a bug where the boss wouldn't execute laser cannon attacks when moving to the right.

Cooper added a new burst mode to the game, which can be switched between the shipyard and shield. He also changed the font in the game to a more suitable one.

Additionally, some bugs were fixed, which were discovered during testing by the development team:

Health bar display issue.

BGM not looping.

Z-order issue with the player's cursor.

Logic issues with upgrades in the shipyard.

Boss bullets being prematurely deleted when approaching the screen's edges.

Burst usage counts not resetting in new levels and some other variable setting problems.

#development #playtest #iteration

WEEK 11 Development & Playtesting

#assignment 3 #development #playtest

I have taken over the shipyard and enemy's programming design. With that being the case, I need to first complete the overall framework of the game and then gradually fill it in.

First, there should be a start menu.

Next are the levels.

Then comes the shipyard.

Finally, the completion interface.

At this point, the entire game can be played. I discussed some enemy designs with one of the team members, and he created a draft design for the enemies, which I implemented one by one. Since he submitted it late, I didn't have time for further communication, so I made some modifications to the parts that were not very clear on my own.

The enemies are divided into 4 categories: rock, soldier (thinking about it now, "fighter" might be a better name), elite, and boss. There are two types of soldiers.

Rocks are generated around the screen and move toward the player.

Soldiers are generated a set at once, rather than individually, and they have fixed movement patterns:

A: They appear from the left or right side of the screen, move horizontally, and fire at the player. After going off-screen, they reappear from the other side, repeating this cycle until they are eliminated.

B: They appear from one side of the screen, move horizontally, but when they reach the middle, they perform a circular motion and fire at the player, with bullets lined up in a column.

Elite enemies move in a figure-eight pattern and have two types of firing modes: firing a circle of 12 bullets in all directions and releasing 3 missiles from each side.

Boss enemies have a simple movement pattern, moving slowly from left to right at the top of the screen. However, their attack patterns are more complex:

Normal cannon shots, with two modes: spread shots and straight shots, alternating between them. The spacing between these bullets is enough for the player to find cover among them.

Missile attacks, launching 6 missiles from each side. The missiles track the player's position and deactivate their guidance when they are 50 pixels away from the player, making it easier for the player to dodge.

(From testing feedback, it seems that players don't know how to dodge the missiles or use a 20mm MG to shoot them down, so more hints may be needed.)

When the boss's HP drops below half, it enters a berserk state and fires a laser. The boss moves to the sides of the screen and attempts to attack the player with the laser. The laser first tries to lock onto the player's position, then charges for 1 second, and finally fires. During the charging and firing phases, it cannot continue to lock onto the player, so the player can escape.

(From testing feedback, it seems that players give up on trying to dodge after about half a second of aiming, as they believe it's impossible to break the lock, so a better design may be needed.)

Drops and material collection:

Each enemy's variables are set to determine what materials they will drop. When an enemy is defeated, objects corresponding to these variables are dropped, and their movement logic is the same as missiles. They move to the player's ship's coordinates and collide with it, allowing the player to collect them.

(From testing feedback, it might be better to make the materials move to the upper right corner of the screen, as there may be too many elements on the screen during combat, making it confusing.)

The design of the shipyard is more complicated than I imagined, filled with various conditions, and I haven't written my own functions, so much of the code is repetitive. However, the overall logic is not complex. I used the in-game button design, which is very convenient. Nevertheless, the entire interface is too rudimentary, to the point that some functions cannot be accurately conveyed to the player, so further optimization is needed.

It's worth noting that the game's quality currently exceeds the expectations of other team members, which has increased their enthusiasm. I hope they can participate more in the development and add any code they want. I'll be busy with other assignments for a week, which should give them enough time.

#development #assignment #playtest

WEEK 10 (& the Break) Assignment 3 progress.

#Assignment 3

Revised One-page

I enlarged the size of the one-page to accommodate more detailed content.

Redesigned the levels and added a simple story to them.

Included instructions for the Shipyard's UI and functionality.

Provided a detailed explanation of the enemy's movement logic and

Described the transition logic between the combat levels and the Shipyard.

I have set up a Discord channel for members to communicate. Since we have three members, the work on GDevelop has been divided into three parts and I plan to complete part A myself.

A: player / player ship / player weapon / targeting AI for missile & 2ndary turrets

B: enemy / enemy AI / enemy behaviour / enemy weapon & bullets/ level design.

C: shipyard / shipyard UI / upgrading mechanic / description /menu.

Under the tutor's guidance, I added a playtest timeline:

Week 10

All basic functions will be tested individually by the development team (us 3 members), including minimal game process.

Week 11

All MVP functions will be tested by the development team. Eliminate all bugs and unreasonable designs as possible as we can. This also makes our prototype playable and run smoothly.

Week 12

Recruiting 5 naïve players to playtest our prototype. Improve the game based on their feedback.

Week 13

Ask those 5 players to playtest our prototype again. This time, we will provide them any necessary information they need. After that, Improve the game based on their feedback.

Week 14

Finish the assignment.

I know that the workload for this project is not small. If we don't start working on it quickly, we won't be able to keep up with the timeline. So, I started coding during the mid-semester break. The first thing to do was to add various variables to the project. This game has many constants, such as the attack power of various weapons, upgrade costs and descriptions, level names, and more. These constants are stored in global variables because the game has many levels, and the player can die, which means they will either restart the level scene or delete the player object. Additionally, grouping this data together makes it easier for designing save and load functions (although they are not needed at the moment).

Next is the targeting AI. I had previously attempted automatic targeting for missiles in the asteroid project, and it worked well. However, the AI for secondary turrets is a bit more complex; it doesn't just fire at random targets but prioritizes them. I divided the possible attack targets into three categories and designed different targeting priorities for three types of secondary turrets:

· 40mm Gun: Prioritizes medium targets, followed by heavy and agile targets.

· 40mm Plasma: Prioritizes heavy targets, followed by medium and agile ones.

· 20mm MG: Prioritizes agile targets, followed by medium and heavy ones.

There are two reasons for this design, differences in movement speed and damage/defense:

· The difference in projectile speed and target movement speed determines that weapons like the 40mm Plasma have a hard time hitting fast-moving targets, so their priority is slow-moving targets. I didn't add ballistic prediction to the turrets (nor was it necessary).

· The impact of damage and defense, for example, the 20mm MG has very low single-shot damage (2-4). If it were to attack high-defense targets, it would likely only inflict 1 damage (I set the minimum at 1), but it has a high rate of fire and DPS. So, having it attack a target with no armor allows it to maximize its DPS potential.

The specific implementation process is as follows:

· The turret first tries to lock onto a high-priority target. If successful, it skips the remaining steps and fires directly.

· If the first step fails, it tries to lock onto a secondary priority target and then fires. If both of the first two steps fail, it locks onto a tertiary priority target and fires.

· If all of the above three steps fail, it means there are no targets within range, and it cannot fire.

(Here, 'type=3' refers to the 20mm MG.)

#development #assignment

WEEK 09 Assignment 2 progress - OnePage

The next step is to add more in that game:

A complete level design, data storage.

New spawn design in each level, including spawn rocks, soldiers, elites and final boss.

Numerical design on enemies, damage, defence, hp, and their drop when killed.

The shipyard and upgrading UI.

Numerical design on weapons and hull, damage, rate, range, cost, etc.

Implement upgrading, change images when starting a new level.

Artwork, visual effects, sound effects.

But let me starts at making the OnePage.

On the top of the page, it shows the key process of the game, which means the cycle of fighting and shipyard.

On the left side of the page, I want to show the main UI, the fighting scene. It will explain how to control the ship, then how the enemies spawn, move and what will drop when they die.

On the right side of the page, I want to show more details of weapons and upgrading. So, I designed 3 different tables to show these details. It takes me lots of time because I have to balance data like the DPS and cost of each weapon.

Unlike the main turret, secondary turrets are more diverse. Standard (green) one shoots normal bullets, with no pros and cons. Plasma turret (pink) shoots plasma bullet that can deal more damage but has a slow projectile speed. So, it is hard to hit the fast objects. Machine gun (violet) shoots fast and the projectile speed of the bullet is also fast, so it can be used as point defence weapon focus on incoming targets like enemy missiles.

There are also 2 types of missiles: missile and torpedo. The former can track and is fast but does low damage. The latter does the opposite. The ship hull can also be upgraded in order to install more weapons.

In my opinion, these details should be enough for assignment2. But still, more details on enemies , including their behaviour and numerical design, need to be done after I found a team.

#Assignment

WEEK 08 Postmortem on Racing car

#postmortem

It looks like a simple game that can be easily made, but it is not. It needs more realistic features than others, such as tree moving and traffic. I can create a whole level with fixed trees and traffic like what I was done in the platformer game, but I choose not. The game needs more randomness and dynamic traffic. Besides, I want to try creating and deleting objects in certain conditions. That is where the idea “distance” comes from.

However, the programming process is more complex than I thought. I have to separate the cars that appear in front of me from the cars that appear from behind me because I encountered some bugs that 2 cars will show up together in front of (or behind) me and block all lanes. In addition, this game design also requires more math than the other 2, though I can foresee that there will be more in assignment 2.

Anyway, by designing these 3 games, I have gained confidence on using GDevelop and designing more complex game in assignment 2.

#post mortem

WEEK 08 Assignment 2 progress - OneSheet

#Assignment 2

The game for assignment 2 is based on the asteroid game. I have tried several weapon implements, so far so good. They work well in a simple scene, destroying every rock. But it cannot be called a game, it needs a complete game process. Simply put, the entire game process is divided into 4 parts:

Level starts, kill every enemy, and loot.

After each level, go to the shipyard, upgrade weapons and ship hull.

Go to new level for more fighting and repeat this until meet the final boss.

Kill the final boss and complete this game.

I abstracted these steps into single verbs: fight, collect (loot), upgrade and combine. Then I created a slogan for shipyard, and is also the pursuit of players: Larger, Numerous, Mightier.

The “flow chart” style image shows the process of player growth, from a small ship with 1 weapon to a big ship full of different kinds of weapons, fighting against the final boss.

According to the CRA sheet, I have added some information such as title, platform, genre, single player, name and contact details.

#Assignment

WEEK 07 Development on Racing Car

#development

I should add some traffic. There are 3 types of traffic:

Same direction and ahead of the player’s car

Same direction but behind the player’s car

Opposite direction

I set the maximum speed of player’s car to 500, and the maximum speed of AI cars to 250, so that player can overtake them. Distance is the only criterion to measure whether to refresh the car. Distance = Relative velocity * Time. The relative velocity of the car in the same direction is the player's speed minus 250, while the relative velocity of the car in the same direction is the player's speed plus 250.

In this way, if the player has moved a distance of 450, a car will spawn ahead. If the player is slow or stopped, and the distance reduced over -450, a car will spawn behind. As for the traffic on the opposite side, as long as the distance reached 450, a car will spawn.

There are 2 positions can be spawn a car, the inner lane and outer lane, it is controlled by the random value of “RandomForCarPosition”. And I also tried a way to change the colour of the car, by the effect called “Color Replace”, the “RandomForCarCS” controls the colour system. Because the colour of player’s car is red, so the car in the same direction should be different from red, such as in blue colour system or green colour system.

The car spawned behind should avoid the player, so I did not use a random value to control the position. If the play is in the inner lane, then the AI car should spawn in the outer lane, vice versa.

The car in the opposite direction is simple. I did not make a complex rule for spawning them.

The left work is deal with the car accident. I did not delete the player’s car when collision, I hided it because if I delete it, I felt difficulty to re-create one in the same position.

The Boolean value Alive can be used in many ways. After all, I did not delete the car, it can collide other cars after it is hided. So, if Alive is false, the player car will not collide with other objects.

At the end, there still some cleaning work to do.

Well, moving the last tree to the front (no need to delete & create) sounds like an excellent idea, but I do not know how to do that.

#development

WEEK 06 Weekend Development on Racing Car

#development

After I have finished coding the left and right rotate, I want to try making a racing car game that player can control the speed, so, I used a different way from what I had learned in the workshop. (Notice that I added a condition to judge whether the player is alive.)

Press E to speed up, and press D to brake which is three times more efficient than acceleration.

The speed and how much distance the player moves are keys to control the object like trees and other cars. This means that if the player does not move, trees should not move, and only the play has moved for a certain distance (250 pixels), I can create a new tree object “ahead of” the player car.

In this way, I can fully control the trees.

I also added a speed display panel and some distance display panels to monitor data when developing. I can change the speed panel if I can find a proper image resource. Other panels should be deleted after development.

#development

WEEK 06 Weekend Elevator Pitch of Racing Car

# Elevator Pitch of Racing Car

#elevator pitch

Title: Speed Mayhem

Speed Mayhem is a top-down 2D racing game. Players drive their own vehicles to compete with other players on busy streets. There are many ways to score in the game; reaching the finish line earns points, crashing into other vehicles along the way also earns points, and players can even equip weapons on their vehicles. In summary, the objective of this game is not just to reach the finish line but also to cause destruction and entertainment.

Sell points:

Thrilling high-speed racing.

Entertainment through destruction.

Diverse weapon choices.

How to play:

WSAD or arrow key to control the racing car. Click left mouse button to fire at any target. Click right mouse button to switch weapon (if the player has).

#elevator pitch

WEEK 06 Development on Asteroid, postmortem and feedback

#development

This week, I want my ship to fire. I have designed 3 different ways to fire, they are: Main Gun who shoot laser, Secondary Gun who shoot bullet, and Missile Launcher.

The easiest one is Secondary gun, I just changed some code in the workshop, and make some copy and paste because I have 5 such guns, then they can fire normally.

In my plan, the Secondary gun should fire automatically because if they fire at my cursor, then they may have the same gameplay with the main gun. Besides, the secondary gun should have limited range, letting them fire at my cursor is not a good idea because the target may out of range.

Here is conditions and events of the left and right secondary guns. The range is 350 pixels, and the left gun only fire at the left, right gun only fire at right (by compare the X coordinate). The front gun and the back gun also have the same design, but they are comparing to the Y coordinate.

The bullet hit is simple, reduce the HP of target, if it is below 0, then delete the target. I did not find a proper explosion effects for the target, but I did find one for hit, so it will display when the bullet hits the target.

Object group is my attempt, I'm not sure yet whether it will work well. But so far, so good.

The next step is to design the laser. It's a lot more complicated than I thought. First, the laser will not delete when it hits the target, it will go through. So, it must have a built-in timer, it is a cool down timer it takes to deal damage. Second, the laser is long. I have to change its origin and centre point to the edge so that the laser looks like shooting from the gun not breaking out from the gun. Third, it is hard to display the explosion effects at a proper location. It should display where the hitboxes overlap, but I did know how. So instead, I let the effect display at the centre of the target and made some random shifts (-30 to +30). However, this method still has another problem: if a laser hits 2 or more target, only 1 explosion effect is displayed, there should be more. So, I changed my mind. I always think about how laser hits the target, why shouldn’t I think about how the targets been hit. Then I had an inspiration.

Now, the laser woks properly. The rest is some optimization work. I noticed that my main gun is a dual-barrel weapon, so the lasers should be fired alternately. I used a Boolean value to determine which barrel should fire.

The next step is the missile. I did not find the proper image of missile launcher, so, I just assume the missiles can be launched at the wing tips.

When a missile is launched, it should find a target and move towards it. In addition, it should seem to have some inertia. After some trying, here is the final setting:

The Rotation speed should have some limit, I have tried 720, 580, etc... and 360 per second is the best solution. So, the permanent force is like the thruster and the guiding part only rotates the missile. The missile should have some flying time limit, otherwise, I can accumulate a lot of missiles on the screen when there are no targets. Also, I wanted the missile to start guiding a short time after launch, so it looked more realistic. Therefore, I have set some time limit: 0.3 seconds after launch, the missile starts to guide. The missile can work for 2 seconds, after which it can no longer guide and accelerate, but it can still fly in a straight line by inertia. It will self-destruct in the 3rd second regardless of whether it hits the target or not.

The launching part is similar to the main gun, but I set it to fire with the right mouse button.

Here is the data of various weapons:

Main gun: Damage: 5, Interval :0.1s, can penetrate multiple targets in a line.

Secondary gun: Damage: 2, Interval :0.1s, with 5 turrets, can attack targets in all directions, and the range is limited.

Missile: Damage: 50, Interval: 1s, can automatically track targets, but flight time is limited.

Finally, I added the HP bar and spawn rocks around the screen:

Now, my game looks like this:

Postmortem:

During the development process, I encountered many unexpected problems, the most obvious being lasers and missiles. But solving the problems was the most interesting step. I spent a lot of time to deal with them. If I have time, I will try to allow players to change and upgrade weapons. In addition, the enemies should also be more diverse. As for the base, I am afraid I can only leave it to the future.

Feedback from Frank

It's simple, I like it

Controls are easy (also who tf uses esdf not wasd lol)

I love the auto-turrets

the explosion visuals are cool, like whenever the bullet hits an asteroid

the parallax background is cool

I like the design of the ship and the turrets

the asteroids being different speeds and not perfeclty lined up to you are cool

yeah

I feel like the scaling is off on a few things, like the ship is huge (Me: I feel the same, will be improved, but not too much because this game also requires the player to TANK some damage)

the pink lasers are HUGE and could maybe be a little shorter (Me: I will keep the current design, I have even thought about making the laser longer.🤣 )

the ship not rotating is weird, but if that was the plan then that's all cool (Me: Because the turret can be rotated, I haven't done any ship rotation yet.)

some sort of score system would be nice, or an end-game, be it "YOU WON" or "YOU DIED LOL" (Me: This will definitely happen in the future. 😎)

#development #post mortem #feedback

WEEK06 feedback and postmortem on Journey of Notes

Well, I did a lot of playtests during the development process, so now, my focus is on other player’s feedback.

I have received a feedback on gd.game.

I want to say thanks to Harry.

For the 1st point of feedback, I have changed the position of UI so that it is unlikely to cover the character.

For the 2nd point of feedback, I have checked the collision mask, that is a mistake, it should be a triangle, but it was a rectangle. I have corrected that.

I switched to the “Analytics”, and I got an exciting result: 29% of the players have played more than 5 minutes.

The whole process of playing my prototype with only 1 level is a little bit more than 1 minute, this means 29% of the players have played more than once.

I have to admit that my game is not easy, and it is not perfect. I really appreciate their willingness to try again and again.

Postmortem:

I encountered many challenges during the production. Choosing music was the first, how to edit the levels was the second, and then there were gameplay difficulties, especially compared to Geometry. In order to prevent players from dying if they make a mistake, I can only design a few types of obstacles, which is equivalent to constraining myself. However, after I got some inspiration, these problems were solved. At least for a game with only one level, the richness is not bad.

#development #feedback #post mortem

WEEK 05 development on asteroid

#development

The first work is choosing some nice art resources.

This one look good. It is a CC0 resource. However, the ship may be too short to install multiple secondary guns. I stretched the image resource to 2x the height, and it looks better now. I have designed 1 main gun slots in the centre, 5 secondary gun slots around the main gun, and 2 missile launcher slots at the wing tips.

Then I have changed the control method. I do not like the idea that the ship moves towards the cursor. So, I change that into using arrow keys or EDSF and limited the moving area:

The turrets must “install” on the ship, which means they must be anchored at the slot point.

Now the ship looks powerful enough.

Because this game sets the right side to 0 degrees, the resources of these guns have been turned to the right side by me. And I have to rotate them to facing the north when the game begins.

As for the main gun, it always faces the cursor.

#development

WEEK 05 Elevator Pitch for Asteroid

#Elevator Pitch

Title: Space Scavenger

Space Scavenger is a 2D Roguelike shooting game. It is like a spaceship version of Vampire Survivors, adding a base. Player drives a spaceship, fight against enemies and rocks, collect the wreckage and ores to the base, and then upgrade the ship and weapons. Players need to choose the weapons wisely according to the potential enemy types in the level. At the end, the character needs to revenge on the boss who made his/her life miserable.

Selling Points:

The shooting game itself is very exciting, a large number of enemies and bullets make the game more exciting.

Easy to get started and easy to be played on a smart phone.

The Roguelike game allows the player to play repeatedly. Increase the cost performance of the game to enhance competitiveness.

How to play:

Fighting: Uses arrow key to move, press left or right mouse button to fire main weapon and the boom. In addition, there are lots of secondary weapons which will automatically fire.

Level: Each level lasts about 60 seconds. Every 10 levels there will be a boss. The 3rd boss is the final boss. When complete each level, the player can repair the ship, install new weapon collected from the enemy.

Map: Map shows the level tree which means there will not be only one path for players. Players can view the basic level information prior to access into or pay for detailed information.

Base: When defeated a boss, the player can return to the base, refine ore, upgrade the ship, or do some research.

Base Construction: Player can also upgrade the base. These upgrades are permanent which means they can be available even the player restart a new game.

#elevator pitch

WEEK 05 My prototype

Here is the link:

Journey of Notes | Play on gd.games

You are very welcome to play my game. Please feel free to leave any feedback, as well as the screenshots of the feedback page if you like.

#development #playtest

WEEK 05 Development on platformer

#development

I added a menu scene for my game. Firstly, it should have one. Secondly, I found that the music will not be played until the player interactives with the game.

There is another purpose of this menu scene, to preload all the music and sound resources. Only after the preloading process, the massage “Please press Space to continue” can show. But I did not find a way to detect weather this process has done, so I just put a timer here, and let the massage show after 2 seconds.

I gained an inspiration when I was playing Rhythm Quest.

Rhythm Quest is a 2-button rhythm platformer game. Jump, attack, and fly to the beat through upbeat songs that are hand-crafted to highlight

So, I designed the second monster, which will take 2 hits to kill. When taking the first hit, the monster will change into a normal monster, and will move back a little (75 or 113 when the player is in the 4th part) so that the time between 2 hits is exactly half beat of the music.

I also set a variable to keep the monster invincible after the first hit to prevent this monster from taking 2 hits in 1 player attack. After the monster taken the first hit, it will change into “weak” status which means it can be killed by another hit.

So far, my game is still lack of different decision. In order to improve this, I added the functionality of double jump to the game. It requires more complex and precise operations and provides extra bonuses. However, if the player ignores that, the game can still continue.

Finally, I added an endpoint to my game, and a feedback interface.

The feedback will record key events. This can help me analyse the design of the level.

Next, I explored the use of random numbers. When the player moves, I want to add some effect like wind. So, these “wind” will appear at the right side of the screen and moves towards the left. After they moves out of the screen, delete them. When the players is in the 4th part, there will be more colourful (from 1-7) and faster wind.

The game was published on gd.games. I will put the link in the next blog post.

#development

WEEK 04 Weekend

#development

I have thought a lot about more ways for interaction between the player and level. This can increase the player's sense of engagement. My initial thought was to allow the player to grab something by throwing a hook. But it is difficult to fit the beat because there is a time delay between the action throwing and the grabbing. I want to design some actions about that when the player presses the button, the game will give feedback immediately. After taking the lecture, I thought I can use melee attack to clear some obstacles or monsters on the way. Due to the obstacles is for avoiding (jump or duck), the monsters are suitable for attack. I do not want players confused about weather they should jump or attack.

After a lengthy selection of resources, the look of my game has drastically changed.

Also, I have added a HP bar and a note collection panel. (This screen shot was added a few days later)

The main actions for players are:

Attack (press J to attack the monsters)

Jump (press Space bar to jump over the obstacles)

Duck (hold S to duck the laser)

The main collection are:

Heart (to recover the player to the max HP)

Big Note (can add 10 note collection)

Note (can add 1 note collection)

I did want the camera to move when the player is jumping, so I created an invisible object like a ghost player who will run as same speed as the player do but will not jump. Then set the camera on the ghost player, and an offset in order to keep the player at the right side of the screen.

The whole level has 4 parts, corresponding to the 4 parts of music. But the music is too long for the first level, so I only kept half of each part. I used the offset function to control that, triggered when the ghost player hit the music control object.

Introduction

Use the “forest” background image and green platform.

Introduce the action of attacking and jumping.

2. First Melody

Use the “grass” background image and the yellow platform.

Dense monsters require players to be proficient in attacking actions.

3. Second Melody

Use the “ice” background image and the blue platform.

Introduce the action of ducking.

4. Climax

Use the “fall trees” background image and the red platform.

The player will speed up to increase the difficulty.

Combine every situation (laser, monster, obstacle) that needs all actions to deal with.

#development

Trending Blogs

Recently Viewed Blogs

Development Blog (for IGB220)