n11592907 - Tumblr blog

n11592907 · 11 months

Text

Assignment 3 Iteration and Changes

There where some key changes that had to be made before we began playtesting with naive play testers. Here are the key changes that I made:

I assigned enemies point values and implemented level changes for when players reach the point value. This was eventually changed by me because of play tester feedback which wanted the level to end as soon as the player reaches the goal point value, this was not done originally because our group planned to make it so that the points a player has at the end of the game is tracked and the player can play again with the goal of earning points. This was eventually scrapped, and the level was made to end as soon as the players gets the target number of points.

After the key changes were made playtesting began.

Most of the work I’ve done on the game from this point onward has been fixing issues found by play testers. Although there are some changes that are worth mentioning.

Players found the game to be very difficult, especially with the difficulty spike from level 1 to 2. To help lower the difficulty spike I added a repair system to give players health after a certain interval of time. This would passively give players health and make combat less difficult since they don’t have to play flawlessly to survive.

Another notable change that was added to lower the difficulty of the game was giving the players power ups. The first part of this was changing some of the players code to make the movement speed and fire rate variables. This allowed for me to make other code that temporarily changed a variable when something happens (for example player collides with object). The three power ups I decided to create was one for healing, one for movement speed, and one for fire rate. These would later be refined by another member of the group and be made so that killing enemies build up a meter that allow players to trigger the power ups, the health and speed boost stayed however after the ships shooting was changed later, the fire rate power up was changed to no reload (more on this later). With this the power ups were added to the game and refined.

One system that I experimented with was the ships shooting (which play testers found to be overpowered), so I tried to implement a type of reload system. The system was based off of a game that I was playing around when I tried to implement this change, the shooting system was fundamentally similar to the what the weapon called the L-Star functions in the games Titanfall 2 and Apex Legends. The weapon would build up heat that would over time dissipate, but if you get too much heat it overheats and you can’t shoot for a set period of time. The idea of this is to create a weapon that encourages timing when you shoot and not spamming shots. I attempted to create this system in GDevelop, however never found a way to make it functional. Eventually it was replaced by a standard reload system added by another member of the team.

This was the last change I made as many of the other large notable changes were done by other members of the team. Most of the rest of this class and assignment were spent on writing and playtesting (my role as a play tester for other groups on the playtest party). Unfortunately, in these last weeks I couldn’t spend as much time on this class as I would have liked, but I did as much as I could.

Something I will talk about before ether end of this week is my experience as a play tester for another group. I had been a play tester before this for part C of assignment 3 in this class, but I was also the play tester for one of the groups during the playtesting party. Overall, the experience of playtesting was very interesting, it agave me insight to how a naïve play tester might feel. It didn’t give me complete insight since I am not completely naïve, with experience as both a game developer, and with my extensive experience in video games I would never be completely naïve, but the experience was still interesting. The experience showed me what it was like to be given a prototype and have to test it, and it taught me a lot about how a play tester feels in that situation.

#development post

0 notes

n11592907 · 11 months

Text

Assignment 3 Playtesting

This post marks our groups first playtest, it was only a playtest of a very low fidelity and early build of our prototype, however it was still important as it would primarily be a playtest for the movement in our game. In the playtest we had two versions that were mostly similar, only one had a different movement type. I was the main one running it since other group members were busy at the time.

The two versions of the game looked like this.

For this playtest we used our tutor, he played the two versions of the game. Something I noticed while he was playing was that the original movement was while easy to understand, was also very simple in the sense that it may get boring. The second version used tank controls, and while he did say that he enjoyed the second versions movement better, other people may not. The other changes he recommended were mostly about adding things to the game, such as more enemies and similar things, these were already planned changes that we were going to make, however this further cemented the need for them.

Overall, the movement in the second seemed better, although could be changed, rather than be left and right to turn left and right, it could be something similar to a top-down shooter. I will discuss the idea with other members of the team.

#playtest

1 note · View note

n11592907 · 1 year

Text

Assignment 3 Development Post

Group Formation and Discussion

This post marks the start of assignment 3, which is the assignment where we form groups and create a more in-depth game prototype.

Group formation was very easy as our tutor grabbed people who hadn’t formed groups yet and directed them to people who need group members. I and three others formed a group of four and out of pure chance one of the other members created a very similar idea for asteroids that I did, the other two members didn’t mind doing asteroids and so we chose that as our game.

We began discussing what we would do for the asteroids game, incorporating ideas from existing versions made by other group members. As well as this we discussed what these ideas may require and tried to remain reasonable with the time we were given for this assignment knowing that we have four members. One member recorded the main points of our discussion and we settled on.

These are the main points:

Point system at certain miles new things are introduced

Points per asteroids/ships

Newer ships appearing have

New scenes with new difficulties, new elements introduced? E.G. Music, speed,

Camera follows ship.

Tracker that tracks number of ships in a scene

Different scenes with different difficulties. Respawn at beginning of CURRENT scene

Enemies that shoot or follow player

Timer for scene progression and points

Shoot = gain points

Asteroid has health? As the game progresses the asteroid becomes less relevant but maybe slight bit more difficult?

Give enemy ships health (Object Variables)

After this, our group began developing the game for Assignment 3.

My role at this time was to create the basis for the game. This was simple as it was just following what I had already done for my own asteroids game in week 6. It ended up looking something like this.

Note that the UI at this time was mostly for decoration and had not been made to function yet.

There were some issues however, the main one being the sprites, for some reason they started facing up, this was an issue because the sprites ‘front’ was technically its right side. I tried to use the sprite editor in GDevelop to fix this and turn the sprite to the right side, but failed to find a way so I left this issue to be fixed later. Another minor issues was the white line on the background, I figured out that it was a grid placed on the background that I think was caused by GDevelop but have no clue how to fix.

After this some time passed before I did more work on the prototype, during a meeting with the rest of my group.

0 notes

n11592907 · 1 year

Text

Racing Game Post Mortem

Now that I have finished the racing game prototype, I can definitely say that I have learned a few things during this process.

This process did largely make me learn about variables in GDevelop specifically, however in addition to learning more about variables in GDevelop, I learned a bit about variables in general and about how helpful as well as powerful they can be to use in the context of designing a game. Variables were the thing I experimented most with during this prototype, and I can confidently say that it made me think a bit harder about the potential uses they can have and potential things I could do with them in future projects.

The last thing this prototype made me think about, although a small one, was player perspective because the entirety of this game is things moving at you, not you moving towards them. Using perspective and some variables I created the illusion of gaining speed and that is an interesting thing to think about and gives me ideas that could be used for future projects and is just something interesting to think about for game design in general.

#post mortem

0 notes

n11592907 · 1 year

Text

Racing Game Development Post

To start off the racing games development, and the same as the other prototypes, I began by following the tutorial we were provided, and I followed it until it was completed. The only thing that I added at this point was a timer after the plyer crashes that resets the scene so that the player can get back into gameplay quickly. It looked something like this.

This was all the basis of the game, so now I decided to move onto the main idea I was thinking of for this prototype. I wanted to make it so that the game got faster over time, the idea I had for how to do this involved using variables. I began to experiment with this idea.

I created a timer that would activate every 5 seconds, then I created a variable I called speed level that would increase by 10 every time this activated. After that I did something that was inspired by what I had frequently done with points systems and text. I made it so that traffic moving down would be given a starting point of speed but over time would increase in speed, this image below shows how I did this.

I made the speed of traffic have a starting speed (300 for the left because they are going the same direction as you, 500 for the right because they are going towards you) that is added to the variable SpeedLevel which will increase over time, this was also applied to the trees.

I did a playtest of this mechanic myself and realised a notable problem.

As can be seen in this gif if you look closely, over time the trees get further and further apart. This is because I failed to acknowledge the spawn times in creating this, so to fix this I would also have to increase spawn speeds.

So I decided to decrease the timer from every 5 seconds to 1 seconds, I also created a new variable called SpeedSpawn that would be used to decrease spawn times. Since it was going to be used to decrease spawn times, I decided to make it add 0.01 every second so that it wouldn’t be too overwhelming or breakable. I then altered the appropriate objects by subtracting the variable from them

After this the system worked in a way that I liked, It create the illusion of speed and made the game more difficult over time, the only further change was that I set it to every 2 seconds.

With this the speed system was completed and I could move onto something else, which was fixing the points system. If you look at previous gameplay footage it shows that you get 100 points every time you pass by a car and it despawns, but I don’t like that system so I had a simple solution where you would gain them over time. I made it so that rather than the cars giving you points, it was trees that give you points, this simple solution sufficed and made the points system about lasting longer and going faster rather than just dodging the cars.

After this I realised that the game was notably difficult, so I decided to make it easier by adding a lives system, so I created a basic life system with three lives and then tested it, but something unexpected happened.

It took me a minute to figure out what was happening, but I realised that not only does the collision trigger every frame (meaning in this gif it probably triggers close to 100 times or something), but when the death occurs it triggers every frame that the player has 0 health (which is permanently). To solve this, I made some simple and easy changes, I added invincibility frames (iframes) to the car after being hit. The iframes make the car invincible for 3 seconds after being hit meaning this solves the colliding every frame problem.

The other problem was that it would repeatedly trigger the death explosion, to solve this I simply added the trigger once condition to the event, I also decided to make it trigger if the lives are equal to or lesser than.

After this I was mostly happy with the prototype but there was one more thing I wanted to add. It felt like now that there was a lives system in the game, being hit was more common, so I decided that being hit will reset the speed level. This incentivises not being hit because it not only takes away health from the player but also takes away the speed that they have been building up, also impacting how fast they get points by reducing tree speed and spawns.

This was the final iteration of the player collision. And with this I was done with the prototype of the racing game.

#development post

0 notes

n11592907 · 1 year

Text

Asteroids Post Mortem and Racing Game Elevator Pitch

Now that I have ‘finished’ the asteroids prototype, I am overall happy with how it turned out. I have learned a lot about how GDevelop works now, and while I am still mostly unexperienced with it, I have a better idea of what it can do. One thing that was particularly interesting was the behaviours which I learned could be used in some interesting ways and simplified things such as removing objects that go off screen. I also learned more about how to use variables and how these can be used with text in game, this will undoubtedly lead to future use and learning of how to and how I can use variables.

With this I also begin my work on the next project, a racing game.

I am mostly unexperienced with racing games as I was just never a huge fan of the genre but the style of the racing game we are making reminded me of an old Sega arcade racing game called Out Run (a link and image for anyone not familiar: https://en.wikipedia.org/wiki/Out_Run).

I decided that that kind of speed is what I wanted to imitate, and it gave me an idea. For the racing game my elevator pitch goes like this.

Overdrive is an arcade style top-down racing game where your goal is to go as fast as possible and get as many points as possible before you crash and burn, speed increases over time, and so does the danger.

#post mortem #elevator pitch

0 notes

n11592907 · 1 year

Text

Asteroids Development Post

I created the base of the game by following the guide we were provided and ended it with a basic asteroids game.

Following the guide I created a game over screen when the player dies, this is the screen.

This will be relevant later for when I show how it evolved later.

After creating the basis, I noticed that the asteroids did not split into smaller ones after being destroyed so I added this. I made it so that when an asteroid collided with a bullet, the asteroid will be deleted and three of the smaller asteroids will spawn. I realised that the bullets remained after destroying an asteroid, so I made it delete both the asteroid and the bullet.

I also added a point system and made it so that the asteroids will give the player differing point amounts with small ones giving 100, medium ones giving 1,000, and large asteroids being 10,000. This is that the left top corner looked like after I added points.

I noticed that the asteroids will fly off screen, but will still be there so it ends up starting to lag my computer. I added a boarder to the screen and made an event where asteroids will be deleted when they touch the edge. This helped to reduce the strain put on devises running the game.

After creating this I out of curiosity looked at the behaviours to see if there was one for going off screen. There was a behaviour for this so I added this to the monitors and removed the screen edges.

I tried to refine the controls because they didn’t feel very good. I initially made it so that the w key gives the ship a burst of speed to make navigating the asteroids easier. This made it feel better, but the movement didn’t feel unique. So, I tried a strange idea, I applied the platformer behaviour to the ship spite. This was an easy way to add something similar to gravity to the ship without difficulty, this made the ship fall when not moving against gravity. I reduced the speed of the basic movement towards the mouse and increased the speed of the w key movement, this made it so that the ship will fall due to gravity, and the player must use with the w key to survive.

I also repurposed the screen edges that I removed and added a death box underneath the map to kill the player if the fall off the screen. This is an image of it:

The mechanic of having to fight gravity made the movement unique and was an interesting idea that I liked from the previously mentioned Hyperspace Dogfights (https://store.steampowered.com/app/842170/Hyperspace_Dogfights/). My movement was not even close to as refined as there’s was, but that is as expected as this is only a prototype and I am mostly unexperienced with Develop, however it was interesting to play around with the behaviours in a way that was (mostly) not intended, and it had an interesting result.

After the movement I decided to change how the asteroids spawned, because as of writing this the asteroids all spawn independently. I created a variable to make this more random, the game would randomly choose a number between 0 and 2 and this number would spawn the correlating asteroid. This gave the game more randomness rather than it spawning all three asteroid types after a set time, it also reduced the difficulty of the game as there wasn’t as many asteroids on screen at all times.

The last major thing I added was a victory condition that could be reached by getting a certain number of points. I began with 1,000,000 points as the threshold but realised that this was almost impossible and decided the tweak the pints system and the victory condition. I set the points to be 1,000 for all asteroids to make the game simpler and easier, than I set the victory condition to 100,000 points. This meant that players had to destroy 100 asteroids before they win the game, this felt mostly fair and balanced. This was the victory screen for reaching the point threshold.

After all these changes I began to run out of ideas for what to change, and was mostly happy with what I had made, so I began some last refinements to the game.

Something that bothered me is that whenever the player died or won the screen would take too long to go back to gameplay, the solution to this was simple. I added the ability to press space to play again, I also added text to tell the players this. This was the final iteration of the loss and victory screens.

With this I was happy with the game and did one last play test to record this gif, it does not include the victory screen but still showcases the other aspects of the game.

I also realise that there is no tutorial to tell the players how to play (even though the game has two controls). So, I added a tutorial for this exact purpose. It would sit in the top right corner and looked like this.

The very last change I made after the last play test was that the bullets are too hard to see, this is a problem that I had forgotten to fix earlier so I simply changed the colour of the game screen background to create more of a contrast between the bullets and everything else. This is how the final version looked.

#development post

0 notes

n11592907 · 1 year

Text

Platformer Post-mortem and Asteroids Elevator Pitch

This post marks when I stopped working on the prototype platformer. Overall, I’m relatively happy with it, however there where several things that I would or wish I could change but didn’t have the knowledge or skill to make or change. The first thing that I wish I could do better was the dash mechanic which didn’t work the way I wanted it to, and didn’t feel good to use, as of this post I still don’t know how I could have improved it but I still as partly unhappy with the dash. Another aspect of the game that I overall disliked was the tower area, as it slows gameplay and goes against the original goal of the platformer. I originally added it to provide a greater variety of jumps, however it only ended up slowing gameplay and not working well with the movement of the game, it is the only area I regret adding. After making the platformer prototype I have learned a few things, mainly how to use GDevelop better, and have learned a bit about the prototyping process, I hope to apply what I have learned to future projects.

On the subject of future projects, I will be moving onto the next prototype I will make, that being asteroids. I thought about asteroids, and the basis we made following a tutorial and tried to figure out how I could make it unique and “better” in some way.

For this I followed what Tracy Fullerton had discussed in chapter 6 of her book. This chapter discusses some useful information about brainstorming, decided to try and brainstorm ideas for the asteroids prototype. I couldn’t apply everything that was discussed in the book due to this being a simple prototype, this only being a one person deign, and it being mostly following a guide that changing parts of it. I decided to simply focus on mechanic ideas, I also decided to only spend about 20 minutes on this, in this time I created a list of ideas which included:

spaceship on spaceship combat

fighting gravity

powerups

waves

boss fight

leveling up ship

infinite/survival

The list wasn’t very large by the end of it, I ended up deciding to stay focused on the ‘asteroids’ aspect of the prototype, but one idea was interesting from that list, the fighting gravity idea.

One of the games we have been shown that was developed with GDevelop was Hyperspace Dogfights (as seen on steam here: https://store.steampowered.com/app/842170/Hyperspace_Dogfights/) and this gave me the fighting gravity idea, what If I try to create a similar movement system for my asteroids prototype, this might be too ambitious to do and might pose problems in future, but I am curious to try. As such this is my elevator pitch:

Freefall is a game where you have to survive and destroy an endless number of asteroids in earth’s atmosphere to get a high score, this will be made challenging by the number of asteroids as well as the controls of the spaceship you must control.

#post mortem #elevator pitch

0 notes

n11592907 · 1 year

Text

Platformer Development Post

I began to work on the digital prototype,the goal of this was to primaraly explore the controls and movement as this is the core part of a platformers gameplay. Tracy Fullerton states In her book that, "As part of your digital prototyping process, you will want to build models of core systems that you have questions about: game logic, special physics, environments, levels, etc. Additionally, two of the core tasks of digital prototyping will be envisioning your gameplay using the input and output devices of your digital platform." This would be the focus of the digital prototype, I wanted to refine what the controls and core mechanic as a platformer would be, GDevelop already provides the base controls needed (space and arrow keys to move and jump) however all other controls such as the dash will have to be made and refined. With this in mind I began work on the digital prototype.

I had also read chapter 7 of Tracy Fullerton's book, and in that chapter she discussed physical prototypes. I had already started the digital prototype before reading this and I thought about if I wanted to do one. In the end I decided not to, this was due to several reasons. The prototypes we were making where created by following guides, as well as this it is only one person working on the project. I understand that in larger projects with groups of people creating prototypes from scratch, these physical prototypes would help to show a low level vision of what the game may be like. However in this context with me following a guide to create a digital prototype, creating a physical prototype would be partly useless in this context, so I continued the project still learning and acknowledging that this is a critical part of a ‘normal’ game design project.

The first thing I thought of and designed in the game where the basic rules it would follow, most of which were basic for a platformer. In Tracy Fullerton’s book she states that, “a distinctive quality of games is that they are experiences that have rules that define game objects, prescribe principles, and limit behaviour within the game. These rules are respected because the players understand that they are a key structural element of the game, and without them, the game would not function”. With this in mind I decided I needed a way to lay out these rules, I already knew what some of the rules where for example a player cannot jump mid-air. Rules like that did not need to be stated to the player as it is a common rule, however some rules need to be stated so that the player knows them. I found how to add text into GDevelop and decided the rules necessary to mention were the controls, the dash mechanic, and the cloud mechanic.

I stated that space is jump and jumping on enemies will kill them as well as give the player a jump, the next two rules were more abstract with pressing space mid-air to dash, and jumping on clouds gives a large bounce. I decided that these mechanics had to be explained so I implemented some text to tell the player this, I kept the text short, just for fun I kept a secret of what clouds would do. The image below is the first iteration of this text.

This was changed after I experimented with the dash mechanic, this is the new and probably final iteration.

(Talk about dash development, the struggle!)

The fist thing I tried to do was create the dash, this ended up being far more painful to do than I originally thought, the reason for this was a combination of gravity and my own lack of knowledge in GDevelop. I found a way to propel the player forward, but gravity still affected it and caused the player to fall while dashing, as well as this the controls felt weird as the player has to hold the space key to continue dashing. I at this time could not find a solution to the control issue, but I did experiment with the dash. The image below depicts the final results of my experimentation.

The first dash iteration is the first event in the image, it is simple and when the player is both falling and presses space, they dash. The second event is a failed and more experimental attempt, it activates the same way, but it also tries to reduce gravity and implement a timer. Reducing the gravity removes the falling in the dash, however it also slowed the player and required something to stop it, that is why the timer is there, to stop the dash after a set amount of time. This did not work, the timer just simply didn’t work and I don’t know why, this iteration of the dash was disabled, and I decided that I would just keep the original dash, the gravity affecting it did make it more unique and it had grown on me. I also decided to look at fixing the controls of the dahs at a later date.

I designed the first jumps of the level to be simple, they would be an easy way to become familiar with the jump of the game and allow the player to get a feel for the controls. The sprite for the platform was slightly wrong but I decided I would fix it at another time. The image below shows the first jumps.

Later, I added an extra section to the introductory jumps, that required use of the dash. This would, similarly to the previous jumps, be a tutorial for how the dash mechanic works. The image below is the added section.

The first enemy was also made fairly simple, it just moves back and forth on a flat surface, similar to the first jumps it is there it introduce the player to mechanics and to allow for the player to learn on their own. Image below shows the enemy.

This part of the post marks when I read chapter 3 of Tracy Fullerton’s book after designing this part of the prototype. In the chapter she discusses the formal elements of a game, so I decided that I would think about and document the formal elements of my game so far.

The first element was the players themselves as well as how many there are and if they will interact with other players. For this prototype and all prototypes I will do in this class, they will all be single player vs game systems, meaning that it is one player trying to accomplish an objective against the game’s systems and obstacles.

The objectives in this context it is to ‘beat the game systems’ and to make it to the end of the level, and while there is no end of level in this prototype, the goal is still the same.

The procedures (or the controls) for this prototype are all on keyboard. The left and right keys move the player character left and right, and the space key both jumps and dashes.

The games rules are fairly simple, they include:

if you are touched by an enemy you lose

jumping on enemy destroys them

jumping on clouds will bounce you

reaching the end of the level would mean you win if there was one in this prototype

falling off the level means you lose

The conflict is that the player has to make their way around and past the obstacles which include enemies and platforms to make it to the end of the level.

The boundaries for the prototype are the most neglected formal elements as they are partly a passive element that is present. The boundaries of this prototype are mostly the limit of the controls and the physical boundaries of the platforms.

After this I continued designing the prototype. The next mechanic I wanted to introduce was the cloud mechanic, it would add more variety in the level and players can jump on clouds to gain extra height. Creating this was more difficult that anticipated, I needed to first add the cloud sprite, I made a mistake and made it the wrong type of sprite (tiled) and had to delete and re add it. The image below is of the sprite.

After that I had to add the event to make it work, the first iteration did something similar to the dash and “used add force to player” to propel them up. This felt bad, it would be instant and jarring for the player and made it difficult to tell what was happening, so I decided to change it. The second iteration was far better, it used the jump of the player instead, it made it seem like it was propelling the player up, however in reality it is changing the jump speed and acceleration of the player and simulating a jump to make it propel them upward. This iteration did not feel jarring or bad of the player, so this is the iteration I ended it on. The images bellow are the events for the cloud.

The next part of the level that was designed was the tower as I have decided to call it. It is a simple platforming section that requires the player to jump back and forth in a small tower area, the twist is that the tower will lead the player to the first clouds in the level, introducing them to the cloud mechanic (as mentioned previously the clouds will bounce you up when you jump on them). The image below depicts the first iteration of both the tower and the clouds.

After testing the area, I realised that the area needed some improvements, the first f which were to the tower. The top of the tower felt bad to navigate, the player could hit the roof when going t jump form, it and it needed to be changed so I removed part of the roof to make jumping easier. The next changes I made to the area was the clouds, I decided that there could be a better (and slightly crueller) way to introduce the clouds. I added a jump that the player physically can’t do but added a bed of clouds below to introduce the player to the mechanic. I also created invisible walls to ensure that the player cannot make the jump.

I made one final iteration of this area after further testing, I decided to just completely remove the roof of the tower and to implement an extra invisible wall, a new boundary for the player. The player can now easily jump form the tower and fail the jump, and the invisible wall at the bottom will stop players from dying by falling between the platform and the clouds. I was happy with this final iteration and moved on to the next area.

The next area was primarily the cloud introduction in a previous iteration, I moved this forward and added it here. This allows the player to preform a real platforming section that utilises the clouds and builds off what was introduced in the previous area. The image below is this area.

At the end of this prototypes development, I was reading chapter 4 of Tracy Fullerton’s book which talks about the dramatic elements of a game. Similar to the formal elements I decided to think about the elements of my prototype.

The first dramatic element was the challenge and the games ability to make players enter the flow state. This one did not apply to the prototype at all as it is too short to achieve the flow state, and while it could be challenging the prototype as it is has very little challenge.

The next dramatic element is the potential for play as well as the types of players. In terms of the player types, most could be catered to apart from the competitor however the achiever is probably the player type that is catered to the most by my prototype.

Premise, Character, Story, and World building are all things that cannot be applied to this as it is a simple prototype. As there is no real story it would be difficult to find any of these in this prototype.

Doing this type of analysis for both the formal and dramatic elements of this prototype did help me to see how these are applied to and are present in a game. I don’t think I will explicitly do and write this type of analysis for every prototype I make as it will most likely only be helpful to do this to larger and more complete games to get a better understanding of game design, however this small amount has helped me to understand these elements a bit better.

#development

0 notes