avextro

[avextro]

Week 13 - assignment 3 postmortem

There are a few things I’d change next time I do a develop a game part of a group. However, the main thing would be keeping a more formal ‘to-do’ list and keeping track of what is changed in each version.

During development we only used discord to keep track of our progress. This meant that any to-do lists where made as messages sent to a group chat, and any updates on what was changed in a new version was also sent as a message. One issue with this was the messages easily got lost as any message in an active group chat does. Another issue was the formality of it. There wasn’t always a to-do list and sometimes extra things were worked on. While extra progress is good, it is helpful to be able to keep track of these extra tasks, which would be a lot easier if we had used another software to keep track of what we had to work on.

Similarly, if we used a more formal system of noting what was changed in each version, it would be easier to keep track of what has been done, as well as what version to refer back to if you’re looking for something specific that has been changed or is no longer in the game. It would also mean that every new version would have a list of changes made, which didn’t always happen the way we did it.

While all this worked well and didn’t really cause any issues, I could see it easily becoming a problem with a larger project or a larger team, especially one where roles are required to interact and work together closer than we had to.

Regarding the prototype itself, I was rather satisfied with the progress we made with the game. However, if I was to change something about the design of the prototype, it would be the level system. I would add a menu so you could go back to previous levels you have unlocked, as well as showing the levels you haven’t yet unlocked. I would also make it clearer for the player what level they are entering, and what the requirement for completing the level is. Of course, aside from that, I would want to add more levels to the prototype, the current three levels don’t provide much content, and can be completed in a few quick minutes before reaching endless mode. It would be nice to have a prototype where the player gets to experience some progression through the levels, but this would require a lot more effort than simply copy pasting a new level and increasing the score required to win. And thus would likely come in a later prototype further along the development pipeline.

[avextro]

Week 12 - Assignment 3 Iterations and Changes

During our prototyping we made a wide range of improvements and additions to the game. The following is a list of all changes:

-changed the UI layout

-new design for visual aspects of the UI

-added animations and sound effects for destruction of asteroids

-added animations for ship movement (both takeoff and constant movement)

-added animations and sound effects for the ship loosing it’s shield

-added sound effects for taking damage

-added parallax background

-added animation and sound effect for the sip being destroyed

-added a rapid fire power up

-added a super power attack power up

-new sprites and animations for all power-ups

-added sound effect for picking up a power up

-added a soundtrack to play in background

-added a tutorial scene at beginning of game

-improved the start screen

-added a 2nd and 3rd level, 3rd being endless

-added enemy pirates who shoot you on 2nd level

-improve the design of menu screens

-added required menu screens for new levels, improved functionality of existing ones

[avextro]

Week 11 - Assignment 3 Playtesting

For play testing we have created a script to be read to all testers, as well as a pre-test questionnaire and a post-test questionnaire. The script ensures that every tester is given the same information and all tests are fair, giving accurate data. The first questionnaire gives us information about our testers, allowing us to evaluate if they are part of our core demographic and how experienced they are with this style of game and platform. The second questionnaire allows us to get extra feedback from the test, highlighting precisely what aspects of the game the user did and didn’t enjoy, and how they think the game can be improved.

We performed one practice playtest, running through the script, questionnaires, and the game playthrough. This test went well, but we did figure out some changes we should make regarding what type of notes exactly we take while observing our tester, and how we can take the notes.

We then completed 5 playtests, four of which being in a workshop. While not all of them ran perfectly, they were still valuable and gave us plenty of feedback and data to work with to evaluate the strengths and weaknesses of our game, and what direction we would take if we were to continue to develop the game.

[avextro]

Week 10 - Assignment 3 Progress

This week we were put into a group and began to work on assignment three. We decided to use one of the members assignment two as a base, as well as their game they had based it on. We didn’t have to tweak the one page, leaving only the minimal viable product, which ended up being:

Minimal Viable Product Description: The game must have functioning movement mechanics, intuitive controls for movement and attack, a clear and easy to understand UI, two levels to transition between, a success/failure criteria, and a functioning menu for play repetition.

We then sorted out roles for all of us and submitted part A of assignment 3.

[avextro]

Week 9 - Assignment 2 FinalDesign

[avextro]

Week 9 - Racing Postmortem

If I was to develop the game again, I would create some sprites and a tutorial screen for the game much earlier in the process. There are two reasons for this. Firstly, it would save a lot of confusion during playtests for the testers, as well as make the game a lot more appealing and enjoyable. Secondly, when I did finally add the sprites, it required quite a lot of tweaking to make the game about the same difficulty with the new sprites and their new hitboxes. If I did this at the start, this would not be an issue, and the playtests would be testing the actual difficulty of the game, not a temporary difficulty.

Regarding the game itself, I would add a multiplayer mode to the game. This mode would be based on endless and be a simple edition to provide a lot more fun and replayability to the game. Whoever survives the longest would be the winner, and the game would keep track of how many games each player has won, with the player able to set a max score before you win out right. The obstacle power up would also be able to be used to slow the other player down to try and sabotage them.

A concept that really helped me through the process of developing this prototype was chapter 10, specifically the “techniques for balancing your game” segment. After playtesting the game I tried to always make one change at a time before I tested it myself again, even if I had several things to change from the playtest feedback. This helped me gauge the effects better and focus on getting one thing done well, rather than everything done good enough. I also put extra effort into making sure everything had a defined purpose, as this helped a lot when making tweaks for the difficulty. Rather than thinking of the dingo’s, obstacles, and power ups all together as the difficulty, I thought of each part separately and focused on which aspect of the difficulty needed changing, and then tweaked the appropriate part of the game. I noticed this worked much better than my approach to previous games.

[avextro]

Week 8 - Racing Dev Post

The base game was initially made in the workshops. This consisted of a car as the playable character, with other cars moving down the screen which you must avoid. The background also moves down past the screen, giving the effect the player is moving along the road. A collision event was also added, destroying the car upon contact with another car, as well as limiting the car from moving outside the road.

Initially I didn’t worry about skinning everything or playtesting. The first thing I worked on beyond the workshop was adding in dingoes which chase you. At the start of the level, there is a row of dingoes just off the bottom of the screen, and slowly move up getting closer to the player. I added the same collision system the cars had, so that if they touch the player then they die. I then added a timer, and f the player is alive when the timer ends, they in the level.

At this point I completed a playtest. Ignoring the confusion of dingoes chasing a car, the main feedback from this was that the game felt too easy. I took this into consideration, but didn’t make any changes for now, as I planned to make multiple levels. This meant that the current scene could be the first introduction level.

Now that I had a basic functioning template for a level, I made all the objects global objects and made copied the events into external events. This makes it much easier to create new levels quickly without having to copy paste the previous level and rename things.

Next, I started work on the second level. I decided that the difficulty increase would come with the speed the dingoes catch up to the player. At the moment there are no abilities however, so the threat of the dingoes is that they limit screen space you have available, as if you go too low on the screen, they will eat you.

At this point I started implementing some abilities. I added a pickup object which has a random chance to spawn. Once the player has picked up the ability, they can press the space bar to spawn an obstacle (car) right behind them. This then pushes the dingoes back to the bottom of the screen. At this point I also changes the slower moving cars meant to be moving in the same direction as the player and made it so that all the cars were moving in the opposite direction to the player and came quickly. (This was done across both existing levels and became the default).

I now had two levels, one simple level where the dingoes slowly move up the screen, and a second level where they move quicker, but you get introduced to a power up to reset them. I then first did a bit of playtesting myself, and adjusted the speed of the dingoes to something I felt was a fair mix of difficulty and fun. I then did a proper playtest with a friend. This time the tester was a bit confused as to what the point of the game was at first. Eventually they figured it out, and enjoyed the rest of the game.

At this point I decided to add the menu system. I added a main menu, which gives you a brief explanation of the game as well as the option to start playing. I then started work on a third level.

Yet again for the third level I increased the speed of the dingoes. I also added a second power up, which allows the player to move quicker for 10 seconds. However, once I tested this level, it felt too easy. To balance this, I increased the time required to stay alive, as well as adding a second pack of dingoes. This new second back starts a bit behind the first pack, however, is reset differently. This means that if the first pack gets halfway up the screen and then you use a pick up to reset them, the second pack will now be in front, slightly behind where the first pack was. This makes it a bit more difficult and was tweaked until had it feeling good.

I then completed another playtest with two friends. The mini tutorial in the main menu was positively received, with both players stating they would have been rather lost without it. During the playtests I noticed the players both developed a strategy of holding onto the obstacle power up, and waiting as long as they could before using it, not using it until there was a lot of obstacles and they needed the extra space the dingoes were limiting.

To combat this, I changed the way the dingoes reset. Initially, they instantly reset back to the start. I changed this to make the dingoes slowly move back to the bottom of the screen, not quite as quick as the obstacles. This means that the players can’t use the power up last second to free up space, but still can hold it for a little bit without having to use it straight away.

Next, I added a second type of obstacle. Instead of killing you, this obstacle slowed your speed for 3 seconds. At this point I also added a proper menu system, linking you between each level and letting you return to the main menu at the end of the game. I also added an endless mode, which was a copy paste of the third level, but without a timer to win the game once it runs down. I then added some more appropriate sprites and backgrounds. However, as the sprites were smaller, this made the game a lot easier. To counter this, I had to do quite a bit of tweaking with the speeds and spawn rate of obstacles.

[avextro]

Week 7 - Racing Elevator Pitch

Speed Racers

The game is set in outback Australia, playing as an echidna as you race through the outback to escape from the dingoes before they can eat you! Navigate obstacles and deploy your own, using abilities to outsmart the dingoes to make it home safe.

Genre:

-racing

-top down

-arcade

Selling Points:

-Unique take on top-down racing, play as an animal being chased

-abilities to deploy your own obstacles to slow down your predators

-fun and intuitive controls

Audience:

Mostly aimed at teens who enjoy playing arcade style games, with the playful setting and gameplay of the game.

Primary Mechanics:

-movement (up down, left right)

-dingoes chasing you slowly getting closer

-pick up abilities to deploy obstacles to try and slow dingoes

-pick up abilities to give you a speed boost

Controls:

Movement - arrow keys/wasd

use ability - space

[avextro]

Week 7 - Asteroids Postmortem

The main thing I’d change about my development process is the use of global objects as well as external events and layouts. Making use of these features in GDevelop would reduce a lot of duplicated objects and code, saving a lot of time remaking them for every new scene. I only found out about this feature towards the end of my development, and by this time it would of taken more effort than it would save me to remake objects and events to be global and external.

Chapter 6 of Tracy Fullertons book was a big help when I was coming up with the idea for this game, specifically the brainstorming section. Initially I was struggling to come up with a unique and original take on an asteroids style space shoot em up. Normally I would just down and think of ideas in the head, but after having read this chapter, I decided to get out a book and start writing any ideas I thought of down on paper, creating a mind map. After a little while I had plenty of ideas, and then I simple picked a few to combine and tweak, and I had a great idea for the game. Because I did this brainstorming process, I also already had plenty of ideas of features I could add to the game as well as just the basic concept of the game.

Regarding the prototype itself I’d add more player feedback. At the moment it isn’t super clear when you take damage or how much health you have. By adding sound effects when you take damage it would give the player a much clearer idea of how much damage they’ve taken, making it easier to keep track of their health without having to check.

It would also help to add a brief period of invincibility after taking damage. Currently, once you are touching an enemy you cannot take damage again until you are no longer touching it, which can make the game a little confusing. I would add a period of invincibility with visual and sound effects to let the player know, before returning to a state where the player can take damage again (even if they are still touching the same enemy that they initially took damage from). This would make the gameplay much clearer and easier to understand for the player, letting them focus on enjoying the game.

[avextro]

Week 6 - Asteroids Dev Post

During the workshop I created a basic asteroid style game, with player movement, obstacles spawning and moving around which damage you if you contact them, player health and the ability for the player to shoot.

Next, I added a feature allowing the player to kill the obstacle, by deleting them if a player’s bullet contacts an obstacle. I then made then spawn a smaller obstacle if they weren’t already the smallest. Once the smallest obstacle is destroyed, I made it drop a collectable for the player to pick up, which increased the player’s score.

I then added a main menu. At this stage it linked to the current playable level, which became an endless mode.

Next, I completed some playtesting with this simple prototype. This led to some fine tuning of a few mechanics such as the players movement, the speed of the obstacles and their spawn rates, as well as the players fire rate.

Once the playtesting and subsequent changes were completed, I was happy with the base game I had and started adding levels. I initially added three levels copied from endless mode before tweaking the difficulty. I tweaked things such as the spawn rate of obstacles, the players starting health, and they speed of the obstacles.

I then came back to the main menu screen, updating it to include the new ‘story mode’, as well as adding more menu screens to link the levels together. The menu screens between levels also allow the player to return to the main menu, as well as showing your score if you fail, or allowing you to go to the next level if you succeed. Once you complete all levels it gives you the option of continuing to endless mode or returning to the menu. When you die in the endless mode the menu shows your score, giving you the option to retry or return to the main menu.

I then completed some playtesting myself, making sure all the new menu screens worked as intended. I then play tested the game itself and made some slight tweaks to the obstacle spawn rates. I then completed another proper playtesting session with a friend and again tweaked the game. This time there wasn’t much to tweak as the feedback was rather positive.

Finally, I did a bit of artwork for the game. I created sprites for the obstacles and the pickup, as well as a new sprite for the player. I improved the look of the menu screens and changed the background of the game levels.

[avextro]

Week 5 - Asteroids Elevator Pitch

Dingo Stole my Babies

The game is set in outback Australia. At the beginning of the game a cutscene will play as the player wakes up, showing the last few babies being kidnapped as the dingoes run off into the distance. The goal of the game is for the player to get their babies back by invading each of their camps (levels). As the player progresses and returns more babies, they will be able to upgrade their stats in the main menu.

Genre:

-asteroids

-arcade

Selling Points:

-Unique and interesting story, upgrade your echidna as you travel Australia rescuing your babies

-Endless survival mode, how long can you last?

-Loosely based on the classic game asteroids, but with plenty of fresh new features and mechanics

Audience:

People who enjoy playing asteroid genre games or even broader retro style arcade games. Possibly also younger children/teens due it its more laid-back style and setting.

Primary Mechanics:

Shooting ‘bullets’ (spikes) at enemies to kill them

Movement following cursor

Controls:

Cursor to move character

Left click to shoot

[avextro]

Week 5 - Platformer Postmortem

The one major thing I would change about the prototype is the size of the levels. At the moment, the levels are rather short with only few major obstacles. Because of their smaller size, the moment-to-moment gameplay as you move from one major obstacle to the next is rather unfulfilling. If you get stuck at a part of a level it can become more of a chore than an adventure to travel from your last checkpoint to the point on the level you struggle at. If the levels were bigger, then not only could major challenging obstacles be put in place, but smaller easier obstacles could be put between the major obstacles. This would give the levels better flow and give the player something to do as they travel between the major obstacles, rather than just running on flat ground, as that gets rather boring and unengaging.

Regarding my process for developing the prototype, I would plan out how the specifics of a mechanic works better before beginning to implement them. Especially with the double jump mechanic, I had a lot of trouble trying both to get it to work correctly in game, as well as figuring out how exactly I wanted it to function. While I may have still had trouble trying to correctly implement it into the game, better planning out of the mechanic beforehand would have streamlined the process and wasted less time.

[avextro]

Week 3/4 - testing

Testing Insights:

Each time I had a friend play test the game, I tried my best to not say anything and just observe. I took now notes, trying to pay extra attention to what the player seemed to enjoy and did repeatedly purely for enjoyment, and what seemed to frustrate the tester.

Each time the test was complete a simple series of questions was asked:

1) What do you think the purpose of the game is?

2)Did you find it easy to figure out what you were supposed to do?

3)What did you enjoy about the game?

4)What did you not enjoy about the game?

(A separate series of questions was asked when testing the mechanics alone at the start)

I used a different user each time to test to get a variety of opinions and to try and make sure that the game was intuitive for new players.

The most interesting results were when I had someone playtest the third level. At first, there was no prompts or guides to help you figure out what to do, and the user had little to no platformer experience. This caused the user to struggle to figure out that there was a double jump and climbing mechanic. While there was an energy reading, the user also never realised this had anything to do with the abilities. I realised pretty quickly I needed to make it more obvious how the game works and what you're meant to do, which was confirmed when I questioned them after testing.

More interestingly, I noticed they seemed to be getting frustrated at having to go all the way back through the level from the start after failing a jump at the end. While they didn't mention this, I decided to ask if they thought a checkpoint system would make the game more enjoyable, to which they agreed. Hence, the checkpoint system was added.

[avextro]

Week 3/4

What I worked on in GDevelop:

I started with the base platformer I created in the workshops and experimented with last week.

The first step was to start prototyping the movement mechanics. First I worked on the run mechanic, adjusting the max speed, as well as deceleration and acceleration values. These were adjusted and tested repetitively until it felt about right for the character. Next, the jump mechanic was worked on. This was a bit more challenging to get right. An excel document was used to quickly see how different values would affect the trajectory. Once a pool of values had been tested I selected a few that looked optimal and tested them in the game, writing my thoughts on each. I then selected two and fine-tuned them, leaving me with a working run mechanic, and two jump mechanics.

It was crucial to put the effort in to make sure the movement mechanics felt fun just by themselves as they are the core aspect of moment-to-moment gameplay. This was inspired by the concept of playcentric design. If the core movement mechanics weren't enjoyable to play with even on a flat platform, then it would be difficult to design a compelling, fun game around them. Not only would the levels have to be an extra high standard, but they would have to be so while being designed to work with a sub-par movement system, making the entire process much more difficult.

I then got a friend to playtest the game so far, trying out both jump mechanics and getting feedback. I took this feedback on board, selecting the preferred mechanic and making a few adjustments to polish it off.

The next step was to start designing 3 levels. I began paper prototyping before trying to create the levels in-game. This allowed for quick easy iterations as I found what worked and what didn't. Once I had a solid concept I brought them into the game.

At first, only the first level was able to be tested, as later levels required extra mechanics to be added. This first level had a simple design to teach the player the movement mechanics, as well as a few enemies to deal with. I tested and fined tuned the level myself, then added a lives system. I gave the player three lives that can be lost by colliding with the enemy without killing it and falling off the map. If the lives reach zero, the scene restarts.

I then once had a friend playtest the level to see what they thought. Changes were then made to the level based on this feedback, the main one being adding a lives counter. Figuring out how to display this on the scene was a bit tricky, but I eventually figured it out.

Next I created the next level in a new scene, and made a checkpoint at the end of the first level which loads the next level. The second level served as more as a formal tutorial, teaching the player about the abilities of the game.

The main challenge I faced was creating the double jump and climbing mechanic so that they used up energy correctly. This took a lot of work trying different things out, but eventually, it was completed.

The gliding ability was scraped, as it didn't fit the feel of the game, and didn't work well with the view the player had. Once the first version of this level and the mechanics were completed, I tested it a little myself before getting a friend to playtest it. Again changes were made based on the users feedback.

Apart from minor changes to the map (mostly fixing buggy points where the objects weren't placed perfectly) the main changes were 1)adding more clarity and 2)adding a checkpoint system. Dialog boxes were added throughout the map to explain the new mechanics to the user, and a checkpoint was added partway through the level.

This checkpoint box however created a few issues. It seemed to on occasion respawn the player on the previous scene instead of back at the checkpoint after it had been collected. While I couldn't figure out why this was happening and I couldn't completely fix this bug, I did manage to reduce the frequency of this bug.

What I learnt/thoughts on readings:

At first I didn't think that paper prototyping would be that helpful for non-turn based games when I read about it. However, I found it to be surprisingly useful. It made me think more about how my game would work, but more so I found it helpful for designing the levels. It can sometimes be tricky to create a level digitally, as you can't both create new sections precisely while being zoomed out enough to see the whole level and get a feel for the flow. It can also be annoying just slightly adjusting something to get a jump to feel right, then having to play the entire level up to that point and see how it feels, then go back and adjust it yet again.

Paper prototyping helped with this, as I could use the grided paper to determine the jump height and length, easily designing jumps that worked. It also allowed me to clearly see the whole level and rapidly adjust different parts as I saw fit. This process made me think about the design of the level more than I have previously, as before I sort of just placed some platforms that I thought looked fun, tested it and adjusted it until it worked, and then repeated that with new sections.

I also learnt how important it is to get feedback often as you make progress on a prototype. Having someone playtest the game at different points gave me a different perspective and allowed me to make adjustments I wouldn't have thought to do myself. I sort of had an idea of this already, but I never thought about how crucial it is to do this often. If I hadn't got someone to playtest the movement mechanics and waited until I had a complete level, then not only would I have to adjust the mechanics, but I would have to make changes to the entire level to make it work with the new mechanics, wasting a lot of time.

[avextro]

Week 2

Title: Post Pocco

Elevator Pitch: A platformer where you wake up to find your conscience has been transferred to a cyborg in a post-apocalyptic wasteland a few hundred years from now. On your journey to find some sort of civilization and answers as to what happened to earth you will fight scavengers, struggling to maintain enough power to keep yourself alive. From time to time you manage to obtain enough energy to discover the superhuman abilities of your strange new body, aiding you on your journey.

Selling Points:

-solid story behind the game

-unique mechanics lets you unlock mechanics as you progress through the game. Rather than give you power-ups throughout levels, you are given the energy to use your abilities how you chose.

-A mix of both puzzle type platform levels where you must figure out correct ability use, and multi-choice levels giving the player freedom of multiple routes

Controls:

AD or left/right arrow keys to move left and right

WS or up/down arrow keys to climb

E to interact with prompts

1/2/3 keys to use abilities

Primary Mechanics:

-run

-jump

-attack

Secondary (abilities):

-climb

-glide

-double jump

-energy management for abilities

Target audience:

-teens/young adults

-enjoy platformer/adventure games

Genre:

-adventure platformer

Setting:

-futuristic post apocalypse world

Images:

Experimentation in GDevelop: During this weeks tutorial, I made a simple platformer level, with a player who can run and jump, a few platforms and an enemy who moves between two levels. To build on this, I did some further experimentation. At first, I played around with the movement values of the player as well as making different levels with platforms. After this, I looked into how to reload a level. Once I figured this out, I figured out how to detect when the player falls off the map or collides with the enemy without killing it and made the game reload the scene. I then added a lives variable to the player, which at the start of every scene reset to 3. Next, instead of making the scene reload upon dying to the enemy or falling off the map, I made the character lose a life. Once the lives reached 0, then the scene reloads.