Sienna

Although this blog has been a large workload, I am glad to have documented my progress throughout this semester in IGB220. At the beginning of this term I had no idea how to use tumblr and no idea what Gdevelop was. 

Despite the amount of criticism given in regards to Gdevelop, I now walk away feeling quite impressed with its capabilities to help people create a functioning game using little to no coding. At first I struggled and absolutely hated it and blamed any faults in my game on gDevelop. I know now that it was just my lack of knowledge and excuses to disregard these errors. I would highly recommend gDevelop to any beginner and inspiring game designer, as this is a great stepping stone into the designing and prototyping world.

The playtest report was definitely exhausting at times, but I actually found it quite cool to receive and analyse genuine feedback on a game my team worked hard on. Though there were definite flaws, I learnt a lot about taking on all criticism as a positive, as it helps you to improve your work for the future.

I met a lot of awesome new people in this class. I was able to be a playtester for other peoples games which was really rewarding as I could take inspiration for my future games. I loved seeing people who were on the same level as me take on the role of a designer and interpret the fortnightly games theme in their own way. There was always so much variety between everyones games. Giving feedback was something I enjoyed doing as I knew the designers (classmates) really appreciated someone taking notice of little details and the potential in their ideas. 

Overall I am really happy with this semester however I don’t think I will continue this blog in the future as it is quite time consuming when I could be working on more games. Though documenting is always important, I don’t want to do it where its not necessary. :’) It will be cool to read this back in 10 years though! HAHA! Thank you for reading! 

Hey! I polished up both One Page and Sell Sheet.

For the Sell Sheet, I removed some of the text in the main screenshot image in the center as it they weren't looking for direct instructions. We were to pretend as if this was the front of the cake box, so the instructions belonged on the back (One Page). I also rotated the text boxes on the sides to make it seem less structured, fitting in with the theme of the game.

For the One Page, I changed the colour of the highlighted keys on the keyboard just for some more clarity and justified some of the text. I also made the image in the center a little bigger so the tutors could see it more clearly when marking.

For assignment 2, our task was to create a One Page and a Sell Sheet using one of our 3 final prototypes that we made on our own. 

What game will I be choosing and why?

I decided to choose Scribble Shoot as it is the game I am most proud of and would like to further develop with another iteration. I see a lot of potential, and the feedback was mostly positive which is a promising start. One problem with this is that it is difficult to improve on something that is already good. The main purpose of this assignment however is to try and ‘promote’ your game to others and see if anyone would want to make another version.

What is a One Page?

A One Page is ”a reference tool that team members can glance at know what to build or iterate upon. Again, a good metaphor is a architectural blueprint.”

They are to consist of these things:

When making the One Page I knew that although they mentioned having whitespace, I wanted to have the background light green and include a small logo and title in the corner. This would tie in nicely to the theme but wouldn't interfere with the content. I made sure to include everything listed as well as a keyboard to clearly show the controls.

What is a Sell Sheet?

A Sell Sheet “should be an attractive, single sided A4 document that could hand individuals interested in helping to develop your game (as developers, publishers, investors or in other roles”.

They consist of these things:

When making the Sell Sheet, I really wanted to promote it as a messy, lighthearted game. I think visuals play a big role in this, so I spent a lot of time making sure it looked good. I also made sure to include everything listed.

After receiving feedback from playtesters we can review what we did, and what would change for future iterations, and why. 

Firstly after receiving many comments in regard to the climbing ladder function, I would definitely change it to the W key rather than the Lshift key. To be honest, I made it Lshift because I enjoy using the Lshift button when playing high impact games like first person shooters. However, in a slower paced exploration game, this location for climb ladder did not suit at all. 

Secondly, the whole script would have to be rewritten in a way that would change the whole structure of the gameplay experience. What we had although was good for a prototype to get our basic narrative across, would not be enjoyable for a 5+ hour game with a detailed narrative. Players want to be able to interact with the game in one way or another, whether that be completing objectives throughout the dialogue, or choosing dialogue and communicating with Larry. Also as another side note, there would also need to be some sort of a skip/ fast forward option through the dialogue as this is apparent in many narrative games.

Thirdly, the objectives will need to be main focus point for the next iteration. The concept/genre of this game was not linear with the gameplay. Specifically the puzzle solving aspect. Fullerton mentions in chapter 14 that “strategy games focus on tactics and planning as well as the management of units and resources. The themes tend to revolve around conquest, exploration, and trade.”. Despite attempting to make our game a sub genre of puzzle solving, based on the feedback received, the objectives fell short in doing so. In the future iterations there would have to be a number of puzzle designs created for this game. I imagine this would look like one large puzzle to ultimately delete Molly herself from the game, and within this, many small puzzles would be required to progress to the next stages of the game. These puzzles would range in difficulty however, we would also consider our target audience when creating these.

Fourthly, although the sprites used were received well by the playtesters, in future it would be good to see characters created in house using a similar style to the word document. This goes for the music and sound effects also. This would make the game more unique and have a more professional and fitting aesthetic to the game. Also, in terms of the music, this would be used throughout the game rather than just in the game menu as this was asked for by playtesters. 

Fifthly, I would like to not only fix the brightness for the settings, but also incorporate a shop edition to the main menu. This would have unlocks for Molly’s outfits, Larry outfits, maybe some additional clues, or even some new skills. I would also like to have the new game and save game work effectively by writing a file into the computer.

Finally, I would like to add a pause screen, where settings and options can come up, such as different language, save progress, help or quit. This will make a players experience a lot more smooth when needing to gain insight for anything. 

Although some of these are large tasks at hand, they will result in a much more enjoyable experience for the players when the next iteration comes around. Fullerton says in chapter 13, “some of your goals will clearly be of high priority— for example, your core mechanic will be of the highest priority. Others, like a leaderboard, will be important, but fall below your core mechanic.”. I considered this when deciding what the goals would be made for the make of the next prototype. I believe that with appropriate planning, the execution will have the potential to be of a high level. In conjunction to what the team considered ourselves for improvement, the feedback was very insightful and helped to determine the next steps of Molly Malware.

Now that our prototype Molly Malware is finished, its time to playtest! So how did everything happen? Well, Sienna C, Jase and I met up with each of our 10 playtesters, and allowed them to try out our game. With each play tester, we ensured that they had no pre-existing knowledge on what our game was at all so their reaction was genuine. Jase read out the script to each player we tested describing how we won’t be offended by their feedback and that this only to help us get an idea of how we can improve the game to give an enjoyable experience to the user.

During the playtesting process, Sienna C and I took notes on how they were playing the game, and their comments. These were recorded along with the timestamp to indicate how long it would take to complete certain tasks. Fullerton said in chapter 9 that “you think you will remember all of the comments later on, but what you will really remember is those comments you expected to hear or wanted to hear. If you do not keep notes, you will lose all the really important details of the playtesters’ reactions.”. With this in mind we made sure to record to every detail that the player would indicate, making sure not to mis-interpret their expression. This would allow us to further understand what parts of the game needed to be brought up and analysed, ultimately helping with the design of future iterations.

After the playtest, players were required to fill out a survey with multiple questions about how they enjoyed different aspects of the game. The scale was rated from 1 - 5, 1 being strongly disagree, and 5 being strongly agree. Having this allowed us to get more in depth answers whilst still being quick enough that players don’t forget their experience. This also benefits us as it means we can calculate averages and analyse the data more closely. 

We specifically chose to do 10 playtests so that we could get as much feedback and data to analyse. The playtesters were strategically picked to fit our demographic with the exception for some outsiders. Our demographic was people between the age of 16-30 that have an interest in indie narrative game. Six of the people we playtested were within the demographic whilst two were below the age and two were above. This is because although we had a chosen a target audience, there are bound to be minorities that are interested in our game and we wanted to include them in our feedback.

All playtesters were very open to giving feedback and expressing how they would like to see the ideal game in future iterations. This was good as this meant there were no outliers that were either too shy to give feedback, or had no interest. 

Some of the results we received were unexpected whilst others were. Overall people walked away giving 4.4 in interest to coming back for another iteration of the prototype. A few aspects were definitely criticised the most, and that was the dialogue and the ladder bug. The dialogue was seen to be too long and an unnecessary format. Players didnt want to sit and wait for dialogue to pass before having control, people viewed this a chore. The climb ladder function was Lshift however players automatically wanted to press up to go up the ladder understandably. However, when pressing W Molly would jump (unsure why) and this would confuse players when trying to climb. 

Common feedback received:

“Ladders were an issue, unsure where they were, couldnt climb up, unsure of their controls. Thought they were the W key, but were LShift.”

“Too much dialogue in the game. Became uninteresting/boring.”

“Dialogue was hard to follow, refine content.”

“Add a skip dialogue option.”

“The objectives needed work, lack of puzzle solving, too easy, looking for more challenge. Collecting items would be a good addition.”

“Don’t like being deactivated during the first portion of narrative. Too long, want to explore.”

“Graphic of Molly faced in one direction when in idle.”

“Music could be used throughout game, add to immersion.”

After our group was decided and we discussed our strengths and availabilities,  We went through Jase’s prototype and discussed where we could potentially improve the content and add content. Jase had a well thought out concept and storyline already so we decided to stick firmly to that but clarify and refine what our goals were with the next iteration.

Fullerton said in chapter 13 that “a developer’s goal is to produce the highest quality game within the limits of its resources and budget.” When choosing what things we wanted to change/improve/add to the original prototype, we had to consider many things that may affect the final version. This was things such as time, skills, and the engine gdevelop. After making 3+ prototypes I felt pretty confident with making a solid prototype in a few days if I worked really hard. For the video and documenting and analysing part of the report, I was a little more hesitant, however I knew I could rely on my team to help out when I needed it.

The original prototype was entertaining and intriguing for players, however it lacked enough content to really show players what the game was about. This was a narrative styled game with very little narrative context for players. We knew this was something we wanted to achieve with our new version. In the original prototype, players weren’t given firm objectives which left the players unsure of what to do and where to go. This was to be worked into the in game script so that players felt like they had a purpose and a task to fulfil. One major flaw in the original prototype was that when you fell, nothing was there to catch you, you just fell until someone restarted the game. Though this is an easy fix, without it, it can be detrimental to a play-through. The art style was already good, however we wanted to incorporate a more animated feeling to the game, so we wanted to change/add some art designs. We also wanted to add music to further develop the immersion and entertainment for the player. After going over what we thought would be good changes/additions to the game, we asked Jase to write the vision of the game as he understood the most what he wanted to see from the game after the first prototype. We then began to construct our gannt chart, deciding who was to do what parts and a guesstimate of the appropriate amount of time to be spent on each task. When making this, we had to keep in mind the deadline given to us. We had to ensure that all time was allocated wisely and we were not going to be rushed at the end due to the lack of organisation. 

Then we began.

The first thing we wanted to get sorted before actually implementing anything into the prototype, was writing a script. This script would help me understand the storyline Jase had in mind and would allow me to easily replicate statements written on the script into the game. This script took a number of days to be made, however once everything was settled we were then able to crack down on the prototype.

Initially it was planned that Jase, Sienna C and I would divide working on the prototype fairly evenly and same with the playtesting report. However, we realised that perhaps this wasn't the most strategic thing to do, so I decided that I would make the prototype on my own, playing at my strengths. This would work well for Sienna C and Jase anyways as Jase would work on art and music and Sienna C could do a fair amount of the report. The video would be made afterwards so we weren’t too worried about that for the time being. Jase quickly made up a few images of files using the new animated art style so I could begin. I started with the start up (Menu) screen which had a few different buttons that you could interact with, as it can be seen below. 

In the settings scene, I made volume, brightness and difficulty options. The volume was reasonably easy to make with a pre-made function in gDevelop made ready to go, so it was only a matter of linking it up to the buttons and moving the slider along the bar. I added the difficulty option with a coming soon sticker over the top just to entice players with potential further iterations in future, however nothing has been planned at this stage. I did struggle with the brightness however as I was unsure how to create this. I found different effects that were interesting to play around with but none of these worked with the brightness filter I had in mind. I figured I would leave it until I finished working on other parts and I could come back. Unfortunately although I figured out a way I could create the brightness, I didn’t have time to implement this before playtesting. I was going to put a global pitch black layer over the game and depending on the percentage of brightness the players wanted, the opacity of the layer would change. This can be included in future iterations. I also created a basic back button taking the player back to the main menu scene. I added a little robot running off the page an aesthetic little touch to the game.

The next page I made was the load game scene, this was pretty straight forward also, with button sprites and text numbering each saved button. I had the buttons change animation when pressed to show the players which button is selected. The continue button when pressed would take you to the loading scene just for the sake of this prototype. In future iterations, a saved progress file would need to be selected in order to proceed. Although the little red cross in the corner would be the way you would exit a textbox like this in real life, for the game I decided to make it so that players could press anywhere outside of the box for it to close. 

Next I made the new game scene, which required a little more coding than the others. This included hiding/showing text on a timer, the buttons that would change text depending on what is selected and what is written into the input, and the little animated sprites on the side. So, how this would work is that players would interact with the flashing text that would say ‘INSERT NAME’ and this would take you to the input name scene. I made this scene by duplicating the new game scene but changed the box in front so that players were entering a name into a new box on top of the new game box. When writing the input, this would save to a global variable so I can display it in the new game page. So once the player press continue after inputting the name would change to ‘NAME’ and the flashing would stop. Then when selecting what number save button they wanted, the button animation would change to the pressed down (like in load game) and the text would change to the global variable. This worked effectively in my opinion and I was more than happy with the results. 

Next was the loading scene which was easier and just had a molly sprite running back and forth with the ‘loading...’ modifying on a timer. After 10 seconds the ‘loading...’ text would change to ‘Ready to play’ and a continue button would pop up. When specifically making this scene, I had to “keep in mind that you are not creating the design document for its own sake— your objective is communication, so do whatever it takes to accomplish that goal.” (Fullerton, 2018). Although nothing was actually loading in the scene I wanted to replicate and communicate to the player that this would be when the game would set up the gameplay before jumping in.

Then it would go onto the game play. Its worth mentioning that the text used was downloaded and I layered green and purple to match the glitchy/animated aesthetic. I also used the same colours as the main logo. With all of what I spoken about so far in the production in Gdevelop, I just had a bit of fun with it trying to simulate to a normal computer desktop but add small touches that made it unique to the game specifically.

At this stage I realised I was going to be making the whole prototype so I began the long haul. I got the background all set up with the art Jase sent and read through the script. After gaining an understand of what he wanted, I started making the game. I initially made it so that Larry was walking around talking and Molly was following him around the screen, but when I asked for feedback he knew I must’ve read the script wrong. So I had to start again :( which wasn’t fun but I just kept going. 

Fullerton mentioned in chapter 14 that “the goal in this stage is to execute on the functional vision established during preproduction.” I was starting to worry that I would run out of time to make the whole prototype within the time frame allocated. I did have to decide which parts of the narrative I would cut out, keeping in mind that I only had to give insight to the player of what our vision was rather than creating the whole game. I had to also make sure that what I did cut wouldn’t affect the overall story to the point where players felt that part of the narrative was missing. After some time of reading through the script, I cut out one whole scene after the introduction and before the Wordcount level. I feel this was wise and wouldn't hinder the experience for the player.

Once I figured out how I wanted to display everyone on the screen, I started making the first level scene introduction with Larry. This wasn’t too tricky, I just had a timer for the whole scene where Larry’s text box would modify throughout the time. This whole introduction level actually had 4 duplicated then edited scenes throughout because I didn’t think about hiding/showing objects depending on the scene timer, but if i were to do it again, I would make the level one large scene. 

Once the player was able to move and the instructions were apparent on screen, I also created an objective box at the top. The player was able to move around and and climb up ladders before entering the password files document.

The documents scene was split into only two scenes however I think I could've made it into one scene using the showing/hiding objects using a scene timer. So in this level, Larry and Molly meet Dr Menth, which means that a large narrative portion would occur. I decided to allow Molly’s character to move around in this level whilst the talking was happening so that players had the opportunity to explore. This meant that I had to create all of both Larry’s and Dr Menth’s textbox, text and sprite to be centred around molly’s character, staying in screen. This was a pain as I wanted to get the exact positions right and it took a lot of trial and error, but I got there in the end. Implementing the text with the timers didn’t take too long, but then I realised the script didn’t actually have any objective after the narrative portion. I knew players would want a taste of doing some sort of activity, after all, we were attempting to make a puzzle-solving narrative game, so I decided to create a new objective/challenge. A number of robots would spawn, swapping animations on a random range timer. Players would have to interact and press E to delete them, saving Dr Menth’s home and fitting in with the narrative. I created another box in the top right to show how many robots would be left using a scene variable for each time the robot was deleted, -1 from the variable. Once the variable went to 0, the end scene would come up thanking for playing the prototype.

In terms of the game music and sound fx, I downloaded royalty free lofi music to put in the beginning menu scenes. This took a little bit of time, finding a nicely fitting song and finding the setting that would allow it to play through multiple scenes but stop once gameplay would begin. All sound effects used were also free downloads. This also took a fair amount of time to find some fitting ones, however in future iterations I would try find less abrupt and repetitive sounds. I just used 2 for Larry and Dr Menth and rotated back and fourth between the sounds. The sound effects for deleting the robots was fitting and I think it worked well.

This was an exhausting but rewarding prototype as I learnt a lot about gDevelop and pushed its capabilities.

gdev mechanics for game:

Now that everyone in IGB220 had completed 3 prototypes using gDevelop, we were at the stage where we had to form a group with a few people and begin a second iteration of one of our chosen game prototypes based from assignment 2.

Fullerton said in chapter 12 "when assembling your team, you have to look at each person as an individual and as a potential team member. Examine their track record and make sure to talk with people who have worked with them before. Ask about both their individual performance and how they interact in a team.” I took this into consideration when choosing who would work well with me and had a similar goal. This was important to do as I didn’t want to end up in a group of people that had a completely different mindset and personality that would clash with mine.

Sienna Cowen approached me earlier in the semester asking if I could work with her, I didnt know much about her but when she told me about her work ethic, I knew she would be worth having for whatever game we choose to work on. When we began the process of finding a third and final member, we had chosen one of my friends who also had a great work ethic and was very good at solving problems in gDevelop. However, when he pitched his game, multiple people wanted to make it, so we were happy for him to leave, so he did. That was fine as someone pitched their game to us and really sparked our interest. I had actually playtested this game in week 2 (platformer week) and I was thoroughly impressed. Both Sienna C and I were on the same page and persuaded him to join our group. He mentioned to us that he was willing to join only if we were to make his game, and we were both more than happy to commit to this decision. Jase introduced himself, and we began our plan of action. We discussed what times would work for us for meetings, and whether we wanted to complete this assignment online or in person. We all agreed to have a mix and only come in when it was necessary. We also discussed our strengths, mine of which was gdevelop, Jase was art and music, and Sienna C said writing and investigating. This was a great combination of people who had different strengths and would help us with allocating who did what parts in the assignment.

Jase One Page:

Jase Sell Sheet:

I felt somewhat happy with the final prototype of this game. I was happy with the objectives and mechanics however the visuals and general experience was lack luster and felt cheesy. This game reminded me of the tacky little console games set up in the kids room at the pub, and I suppose if you were going for that vibe, it fit right in.. but that wasn’t my intention. I may be being harsh on myself with this result but after feeling so proud about the execution of my last game, I set a high expectation for this one. The fact that I had to completely change the idea was unfortunate, but deciding on this the night before it was due led to some chaos. I tried to further my concept ideas of the swimming environment by adding swimming lanes, swimming flags, multiple swimmers and cheering surround sounds. Though this was somewhat immersive, the rushed art definitely didn’t add too much. 

Fullerton said in chapter 11 that “Learning a skill is hard, but the process has its rewards when you finally master it— even more so when you get to show it off. Presenting your players with the opportunity to learn difficult skills is a challenge, but it is a hollow one unless you provide ample opportunity for them to master and display that skill.”. I think I was able to provide this opportunity to players by introducing a unique gameplay feature by making the objective based around your success using the game control. This allowed players test and determine how good they were at playing the game and being able to try again to achieve a better result. Also have different levels of difficulty opened this up for more opportunity to master the gameplay.

If I was to make this prototype again, I would put a lot more time into the mechanics and playtesting to determine how fast the swimmers should be, how long the race should be, which keys show be used, etc. I would also put a lot more effort into the art and animations, rather than two images looping through at the same rate constantly. I would consider other ways to make the game more entertaining and more in depth as currently its only very surface level. Maybe by adding achievements, local multiplayer, and unlockables. I received feedback on my game:

Positive

“the mechanic (i.e. typing the correct letter to swim) is quite fun and refreshing. Overall, it is a fun game to play.”

“Quite a cool game! Very challenging and the game design works well with the concept!”

Negative

“I found it particularly frustrating at the start and the end of the race due to the random letter (and especially repeated letters, e.g. A, then E, then A, then A).” 

Additions:

“I thought the game would be more enjoyable if the player can see the upcoming 1 to 2 letters so that they can prepare. This may make the gameplay feel more fluid, especially for players with slower reaction time.”

“One thing I would like to suggest is adding a negative consequence for mistyping to make it more challenging! However, I would also suggest not making the other swimmers so damn fast. Maybe also a more accessible keyboard layout rather than ABCDE (something like QWOP or DFJK works well).”

Name: SwimType

Brief Description:

Swim Type is a racing game with a where players put their typing skills to the test. With multiple levels of difficulties, players race the other swimmers to the other side of the pool, either placing 1st, 2nd, 3rd, or 4th. Hear the crowd cheer you on to win the race!

Genre: Arcade

Primary Mechanics: To move your character, different text indicating which letter you must press will pop up. You must press it before it changes to another text!

Setting/style: The setting of this game is at a swimming competition, where crowds are cheering and people are swimming. This high intense racing environment is bound to be stressful for those racing.

Audience/Demographics: This game is suited for everyone who is learning how to type or is a skilled typist. This may also interest people who swim.

Selling Points: This game has a very interesting mechanic of movement that will improve your typing skills whilst having fun! The immersive competitive environment is worth noting, as the main objective revolves around how good your skills are.

After my failed game concept and one night to create a new game, I decided to keep the main letter typing mechanic and create a swimming race game. This is a complete 180 from the dark and in depth concept I had originally had, however I knew I could make this in the small amount of time I had left, have it playable and fit the racing theme. 

Fullerton says in chapter 9 that “people enjoy the opportunity to master a challenge and to fire their imaginations. Games also offer a ticket to relaxation and an excuse to hang out with friends.” I considered and applied this way of thinking when making my prototype. I wanted to give the opportunity to players to improve their skills and reward them when they reach achievements, in this case first place winner. I also intended in making this game local multiplayer in future iterations so that people could have fun whilst playing a laid back yet entertaining game with friends. 

I began deleting everything I didn’t need and started working on a starting and finishing point to the race. I added other npc swimmers and gave them random swimming speeds (upwards force). I recorded who came first, second, third and fourth and would have text pop up to show this. I was able to create three different levels of difficulty, increasing how many letters used in the main mechanic (L1 - 6 keys, L2 - 12 keys, L3 - 26 keys), and increasing the random range the npc’s swim rate. Everything was finally coming together in a way that fit the theme. I created a basic swimming animation for all the people and a background image of a swimming pool with multiple lanes. I then searched for cheering sounds and added it to my scenes. This was a very rushed make, and it is obvious by the art (which completely flopped my original goal for this weeks game), however the game was playable and made sense. I was able to post it online by midday and have people review it. Tune in for the feedback.

Gdev code:

Hey! So I made another game, well actually two.. sort of. Since week one I have had an idea for a game and was told to save it for racing week, and this weeks game was racing! I had thought a lot about this idea and what I wanted to focus on with the make of this game. With my previous game, I wanted to learn a lot about gdevelop and how to incorporate mechanics and store information using variables. This week, wanting to do something different, I decided to have my main focus on the visuals rather than the back end itself. In other words I wanted to make a basic game with extremely immersive surroundings. I wanted the race to almost feel like a short movie. 

Fullerton said in chapter 9, “One way to look at designing a game is that it is a process that makes a vision real. A team often begins with a vision of their game. That vision has many parts and may be expressed in many ways.” I definitely considered exactly how I wanted to execute the make of this game prior beginning. This can be beneficial as I can save time messing around with ideas and get straight to what I want.. However doing this method may miss potential opportunities to make the game even better. Part of developing is trying new things and seeing what design works best. Another problem with using this method is imagining something that you cannot make. This is a big mistake for beginning game designers and I definitely considered this when making my game but decided to try create something I envisioned since week 1.

Im definitely not very good at art (hence the scribble art in the last game haha), but I wanted to really throw myself at it and try to make a game that isnt the typical car racing game. I decided to make a simulator disguised as a race. This concept was originally to be a drowning simulator, highly inspired by the game ‘Drowning Simulator’ itself. In the game ‘Drowning Simulator’ the player would fall off the end of a boat and be required to constantly scroll up to stay afloat, making it a sort of racing experience, in that they are racing against the game. As time goes on, the player would realise that this boat that they were calling out for would never come back, forcing the player to stop scrolling and drown. 

This game was made as an advertisement to life jackets. So I was inspired to re-create this game in my own way with my own style. When I was younger, I practiced typing by playing a game, called ‘Adventures of Typing with Timon and Pumba’. This game had an interesting mechanic that I have not since seen in a game, and this is where players saw a letter on the screen and would have to press it as quick as they could to get the next one. It seems pretty straight forward, but I remember how stressful it was when racing against the clock and unable to locate exactly where this key was. I thought this mechanic paired with the drowning simulator would be a great fit for my racing game.

So before jumping straight into the visuals I had to make my mechanic. The concept was, the player would be constantly sinking, and as they pressed the correct key displayed on screen, the players character would move up an amount of distance. Players would need to press the keys correctly to get to the top of the water before the timer ran out. With the additional constant force down, this would hopefully give the feeling of the player getting deeper into the water. Though this mechanic was easy on paper, I had quite some trouble with making it.

I had to learn about child variables and how to use them effectively, and I found the mechanic would get stuck constantly on a random letter and I was unsure how to fix it. After discussing with many friends and troubleshooting the problem for a number of days, I then had the finished mechanic. I then also incorporated a speed round where players could spam 2 keys for 10 seconds and make a lot of progress upwards. This would break up the repetitiveness of the overall game. After successfully adding this, I was to get into the art of it and increase the immersion level. 

I went with a gradient from dark blue on the bottom to almost white on top to simulate the feeling of being under water. For the speed round I wanted to really spark panic in the player, So I created various dark shadows around the border of the screen and looped them through at a high rate so they would almost flicker.

Gif of speed round:

https://giphy.com/gifs/cX4eL9HEo3jlBZpdEA

I created music to heighten the sensory input drastically, having soft ambient yet eery music with a 10 second frantic overloaded sound for the panic speed round. Everything was making sense so far, before I began realising this game seemed pretty bland. I could’ve added bubbles and seaweed into the water to continue creating the environment, however I felt this would take away from the experience I was trying to simulate. So I began to shift my idea to simulate anxiety, which can feel like drowning. This would allow me to add more and have everything I had continue to make sense. For the next parts, I was heavily inspired by the simulator game ‘Anxiety Attack’. This game would take place in a forest where players would be visually thrown words and lights and sounds to make them feel uncomfortable. However the main mechanic of this game was to time pressing the space bar perfectly to simulate breathing. I decided, similarly to ‘Anxiety Attack’, have disturbing messages pop up throughout the game.

My idea was that this would distract the player from the main objective of the game, to get to the top of the water, which one can argue is similar to real life situations. In the mean time, I had also decided I could do ‘a second level’ where its almost the same thing, however its in the setting of a forest, and the player is running away from a dark mass. 

I wanted the transition for ‘level 1’ to ‘level 2’ to have purpose, and continue the idea of it being an experience rather than a game, so I decided when the timer is close to running out, Ill add a lot of permanent force to the character so they drop through all the progress they had made, and the screen would cut out to black.

I completed adding and timing all of the messages, the scene transition, and was working on the forest when I realised this had nothing to do with racing, at all... I had twisted was racing is to fit it into an idea I had at the beginning of the course. And frankly the gaming experience of this prototype was not good, and everything I made was just a cheesy combination of the games inspired by it. At this stage it was Monday, and it had to be completed on Tuesday morning.. Part Two of development coming up.

Gdev code:

etc.

Hello! This post is about my final result of Scribble Shoot, including what i am happy with, and what I would change in future iterations. 

Overall I am really proud of the results of this game, from the mechanics to the objectives and aesthetics. I found that I was able to execute this game to a higher standard than my previous game, and this was to do with what I had learnt in the making of PipeLine. Fullerton said in chapter 6, “experimental games are those that have been created in an attempt to do something new with games or to make a game design discovery.”. I wanted to create something unique to the classic gameplay of asteroids by adding elements that changed the overall objective. I feel that this experimental design not only pushed me to my limits but I learnt a lot more than I thought I would.  I was able to continue to learn a lot more about various aspects such as timers, variables, trigger once, and & or || conditions. Visually this game is very pleasing, sonically, the sound effects were very fitting, along with the background music, and finally the gameplay itself was really smooth once learnt. Including additional scenes to the two levels such as the introduction, died and display score scenes broke up the gameplay and allowed players to choose what they wanted to do (quit the game, or try again). 

I had a few negative points of my game that I either didn’t have time to change or was unsure how to change. One flaw in my game was that asteroids and collectibles would spawn right on top of the player sometimes and would take life straight away. This would be unpredictable and severely interrupt the gameplay experience, especially if it was the cause of death. A friend suggested having an invisible box around the player and make the asteroids not spawn within the box. This was a great idea however I was unsure how to execute this and didn’t have enough time. Another problem I had

In terms of elements to add in future, I think adding a timer to record the players speed to complete the levels could add another aspect of competitiveness. This would encourage players, similarly to beating a score, to beat a record and possibly challenge friends to do the same. I would also like to add another scene where players could choose their avatar and players could view and select which level they would play. This would gives players more choice resulting in a better experience.

Feedback:

Positive:

“I like the art style that has been used in this game, it’s very creative and suits the theme of the game well. The start screen was helpful to learn the controls and how to play the game.”

“What an awesome twist to generic Asteroid games! I found the mechanic of collecting shapes and delivering them while dodging/shooting asteroids very interesting. “

“On one hand, I found it exciting as I have to make multiple decisions while playing (do I collect shapes first or do I shoot the asteroids? Should I deliver it, or should I collect more points?). This allows for very dense M2M gameplay, which may facilitate tactical immersion.”

“The music and art assets are amazing. I think they all fit very well together.”

“the unique mechanic of collecting shapes and delivering them back to their respective boxes is a good addition to the Asteroids game. Notably, having the player risk themselves for an objective gives the game more direction rather than just survive in an asteroid rain. The Art and music definitely suit this style of game too, the childish “doodle” feel works well with the shape collecting.”

“The bullet bounce mechanic is genius as it forces players not to just shoot constantly as they can destroy the shapes. This means players take more care when they shoot and where. The gameplay was fluid with a clear goal.”

“The aesthetic of the game is amazing! Really like the skribble/doodle art style which gave the game a fun cohesion. “

“I liked the music and it was very cool as it fit the art style of the game. Loops well too as a bonus!”

“I enjoyed the controls very much (WASD thank god). The player movement felt solid and I really liked the physics involved when the projectiles shot out! Lead to interesting skill shots which you could pull off. Also, collecting the shapes was a unique and really interesting spin on the genre and made me want to keep playing.”

“Boost was a really well implemented ability and I liked how it was implemented to act like fuel! “

“Overall really sick concept and unique spin on the asteroid genre. Your gameplay, art style and music flowed together and created immersion which lead me to keep playing. Great work!”

“I liked the cutesy theme”

“Your aesthetic this game is really cool! Love the scrunched up paper! If you drew the sprites yourself, great work, because it is on theme!”

Negatives:

“the character can feel a bit slow.”

“sometimes, there are too many asteroids on the screen that makes it quite hard to collect the shapes, or even survive (or maybe I am not good at balancing priorities ??). In these instances, having multiple objectives (collect shapes + deliver shapes + shoot asteroids) is quite overwhelming for me.”

“A few things to improve on: the dash should probably be WASD orientated and not direction orientated. Having the player move up and dash while facing downwards just cancels the movement out and feels unresponsive when doing so. Another thing you could slightly improve on is the rotating: when the character is rotating, they kinda rotate around the arm rather than the center of the body.”

“The asteroids sometimes spawned on the character so I didn't have time to react or avoid it therefore losing lives so this could be improved in an iteration!”

“The only real feedback i really have is the spawn rate is a little high/frequent, so map fills up fast. I also found an asteroid spawned on top of me which dropped my life”

Additions:

“I’d add the spacebar to shoot to make the game more accessible to laptop users.”

“Make it clear when the player takes damage (i.e. sound effect, flash the sprite)”

Name: Scribble Shoot

Brief Description:

Scribble Shoot is an ‘Asteroids’ (arcade) inspired game with a mordernised and light hearted tone. Players are required to retrieve shapes and deliver them back to their designated container. Whilst doing this, other shapes, varying in sizes, are flying around in random directions, posing a threat to your character. Players must avoid these unwanted shapes, by either dodging them or shooting them with your bazooka. Careful where you shoot though, your bullet may bounce back and hit you!

Genre: Arcade

Primary Mechanics: To move your character, use the WASD keys. Use your mouse to aim your character in a certain direction. To shoot, press left click on your mouse, and to dash, hold LShift. To pick up the shapes and deliver them to their containers, simply move your character to them to cause collision.

Setting/style: The art style of this game is inspired by mobile game ‘Doodle Jump’, with the background being a piece of line paper, and basic sketches as the shapes and characters. The unique yet simplistic music accompanies the light hearted objectives and art style. The background music is unique and simple with a catchy kalimba riff.

Audience/Demographics: Similarly to ‘PipeLine’, this arcade themed game will not only catch the attention of players that took part in the arcade era “from the late 1970′s to the mid-1980′s” (rarehistoricalphotos.com), but will also bring in a younger audience, with its light hearted child like aesthetic. We can predict that this game will also capture the attention of those who played similar games such as ‘Doodle Jump’.

Selling Points:

This game has taken a classic arcade and put a new spin on it by changing its main objective, giving a new gaming experience to both people who have played ‘Asteroids’ before, and those who haven’t. The art style of this game sparks nostalgia to childhood with scribbles perhaps you have once done inside your school books.

Hello! It has been a while! As I am finishing up my new game Scribble Shoot, I thought I would tell you a bit about the development process it took to get the final result. This game was to be inspired by the arcade game Asteroids. Before brainstorming any ideas of how to approach the game, I researched a little bit about the games objectives and main functions. So the idea is, your ship has to shoot all of the flying asteroids to gain points. To shoot your player aims with their mouse. And you must avoid the asteroids from touching you, otherwise you will loose lives. I began thinking about ways I could put my own spin onto the game, whether that be changing an element or adding an element. In the mean time, I wanted to get the basic functions of Asteroids made in my game, which didn’t take too long as we had been given an in depth guide to create this. 

For the make of my game, I really wanted to focus more on the mechanics and learning new skills of gdevelop rather than the presentation of the game. Some of these skills learnt were: object, scene, and global variables, modifying text, deleting/spawning certain objects at intervals, adding and subtracting from different variables depending on actions, etc. So the first thing I wanted to incorporate was a mechanic where the ship (player) was able to move around on the screen. My personal preference for movement mechanics are the WASD keys so I decided to use those. I also wanted to add a speed boost to the movement as an excitement feature, using Lshift to drive that. 

When designing what game I would make, I read chapter 10 where Fullerton says, “Sometimes a combination of rules creates an imbalance. Sometimes it is a combination of objects, or even a “super” object that unbalances play. Other times it can be a combination of actions that provide an optimal strategy for players who know the trick. Whatever it is, these types of imbalances can ruin gameplay. You will need to identify them and either fix the rules that create the problem, change the values of the objects, or create new rules that mitigate the optimal strategies.” I had to make sure to consider what elements I would add that would not take away from the gameplay. 

Idea 1: At this stage I had thought about an idea in which would give a certain objective to the player, besides the ‘get the most points you can’. I had thought about having an object that moved slowly up a straight course and your objective was to protect it. So you would have to move alongside it protecting both yourself and the object from getting hit by asteroids(enemy). These asteroids would come at an angle that would directly hit the object, so the player would have to shoot it before it reached as the object made its way through the course. I believe that these changes to the classic game asteroids would not take away from the gameplay itself but enhance the already existing game, applying what Fullerton had previously mentioned.

Idea 2: Another idea I had was to have the objective of collecting and delivering an item. They would spawn at a timed rate and your job was to pick it up and return it to its designated spot. Perhaps there could be different objects and they all had their specific home. Whilst out trying to complete the objective, asteroids would spawn and you would have to avoid them by shooting them, gaining additional points. But if you shoot and hit an asteroid, or an object, or yourself, you would lose lives. Similar to idea number 1, I think this version of asteriods would not overwhelm or unbalance the gameplay but would become more entertaining with the unique take on a classic, supporting Fullertons text.

I decided to got with this second idea as it would include the most ‘coding’ out of the two. 

I knew a lot of different variables would have to be included in my game so it would be playable in the way i envisioned, so I started making my way through the trial and error phase of getting everything to work. I had to create a few scene variables -  coincollected (boolean to record whether player had object), and coincount (total number of coins to collect). I also had a friend show me how to use object variables, so i incorporated a lives variable in the text to display how many lives left. For the points system, I wanted to be able to display the total points at the end of game (in a different scene) with the potential of adding more points throughout different levels. For that reason i created a global variable to control that. From there I had to link up all the variables to different actions that would occur throughout the game, such as: collisions with bullet, asteroid, coin, container, and movement and spawn rate coin, deleting coins etc. This process took a long time as it was something I didn’t have much knowledge on, but in the end i did have a functional game. Though the difficulty of the game was coming from the asteroids, I wanted to push it a bit further by adding walls around the border of the screen. This was so that everything would now bounce off the walls rather than slip off screen after they spawned. This meant that players would have to be extra cautious of where they shot as it could rebound and hit something you were avoiding.

I then had to create different scenes such as the start screen, if you lost all your lives, or if you passed the game. This was pretty straight forward and was able to complete that pretty quickly. As this first level objective was to only collect one type of coin, I wanted to create a new level where players had to collect 3 different objects and return them to their designated containers. Most was pretty much copy and paste from level one however I struggled with understand how to spawn different objects depending on whether their containers were already full and to stop spawning once they were full. I ended up having a friend walk me through it before completed the core mechanics of my game. 

Once I had finished my two levels, varying in objectives, I play-tested them making slight adjustments like fire rate of bullet, and spawn rate of asteroids, etc. I was very happy with my game concept and execution, and was now ready to start adding the aesthetics (my favourite part). Because this game is light heart and almost childlike in terms of having a straightforward task, I wanted to stick with that vibe by having the art style very loose and a bit messy looking. I thought having sketches with a crumbled lined paper background was very fitting, with mobile game ‘Doodle Jump’ in mind when visualising it. I replaced all objects, like the coin in the first level, with different coloured shapes and drew containers with that shape and colour on the front. 

Shapes art style:

Container:

I wanted something comedic with my player, continuing with the theme, so I decided to have my stick figure man hold a bazooka. 

I did have to adjust all of the hitboxes as they varied in shapes and sizes. The player needed its edit points adjusted as the controls weren't functioning correctly with the shape of my character. 

Upcoming post with final results and feedback from players.

Gdev Code:

Hi again, this post is about my critics on my game and feedback I received from other classmates. Throughout the make of my game, I was constantly playtesting in order to create the best experience for the player. Despite this, my game still resulted with a number of faults and glitches that I was unsure of how to fix. 

In chapter 3, Fullerton said “As a designer, you must define the boundaries of the game and how players will enter and exit the magic circle.” Unfortunately I was unable to set physical boundaries in place which was not ideal as this led to a lot of criticism. Metaphorically speaking, I was able to set these boundaries using firm objective driven gameplay which was received well.

I used Physics 2 behaviour to allow the ball to bounce off all platforms, coins and spikes, however this meant I was able to push the platforms themselves around with the player platform. I messed around with the density of everything with trial and error before coming to the best conclusion I could get within my skills. 

When the ball hit the players platform, at times the ball would go straight through without any form of collision. This is a major problem as it defeats the players role in the game. This would only happen on occasions randomly, so we were unable to pinpoint where the error was coming from. It can be assumed that the G develop software struggles with the Physics 2 behaviour and was the cause of this.

Quite regularly, the ball would bounce from the platforms and get stuck, glitching out and either teleporting it to outside the barriers, or making the ball only travel at one angle and a decreased speed. No matter how the players platform interacted with the ball, it would make no difference. This is another major problem as it interrupts the whole game play, having to restart the game. I believe this has to do with the angles of the platforms and G develop not being able to manage the Physics 2 behaviour well. I was unable to do anything to prevent this from happening as it was important to have some platforms at an angle as a challenge for the player.

Positives:

“This is a very fun and engaging concept!”

“The core concept of the game is quite unique and can very well be engaging to players. The idea that you are a platform guiding an object to the end instead of being a character on platforms is an interesting twist. Music is hella awesome too! Has potential!”

“I love the core mechanic of your game. It feels like you are playing pinball but you have almost total control of where the ball will go. The art style and music choice were very on point too. I am loving the game so far.”

“Overall, it is a very nice game with innovative mechanics. Well done!”

“I really like the idea of mashing up old arcade games like this and making it fresh.”

“I like the spacey feel with the background and music it feels really fitting.”

“As far as difficulty goes I think its pretty balanced. “

“I also thought the actual structure of the main level was well done and had a lot of variety to it.”

“The base idea behind the game is relatively unique for a platformer and is quite an entertaining experience that isn’t a carbon copy of other ones.”

“The aesthetic provided via the art style and music choice blends well into a minimalistic yet pleasing experience for the user to play through”

“The fact there are instructions within the game without having to just rely on the Read-Me is a major plus to the game itself.”

Negatives (and solutions)

“Have the board move faster than the ball itself. More often than not, the ball will bounce away and the player won’t be able to catch it before it hits the spikes.”

“Rotating the platform faster would be good as every-time I hit the ball, I am just not rotated enough. The ball could probably move a bit slower or have the player move a bit faster”

“The ball’s movement seem to be primarily controlled by the physic engine, which can lead to situations where it is hard to gain back control of the ball (i.e the ball is stuck between walls)”

“The spin mechanic is really interesting too. For now, pressing W feels like what would happen if I just held A or D, and I felt that, given it came across as a different mechanic, pressing W should do a new action. Rather than spinning slowly, what if pressing W caused the board to rotate really fast once or twice? Doing this could cause the ball to fly towards any direction, and could potentially be useful when the ball gets too close to a spike and the player just wants to move it away.”

“The game seems to punish the player quite hard if they miss a bounce. For example, the ball bounces toward the starting cell (or section) when the player is already at the final cell (or section), which is quite annoying to retrieve/redirect. Maybe spawn some barriers after the player has passed a section to avoid this situation…”

“I think for this type of game you might want to use something more solid to make the levels out of since the cylinders seemed to be pretty finicky especially when they’re just slightly rotated. I ran into a few glitches with the ball going under tiny cracks and becoming epileptic. One time the ball came back out after going through the ringer and had gravity all of a sudden, so it was super slow and kept sinking to the floor. If the levels were made out of basic pixel art I think it would make it easier to deal with collision and would also suit the whole arcade style thing better.”

“Hit-boxes for some of the objects i.e the spikes are not fitting, some objects clip through each other.”

“There are a plethora of bugs related to the game, with the ability to push walls out of place, clip through things and disappear entirely. It also seems that after the introductory level that your lives reset to 0, instead of the standard 3 as outlined in the Read-Me.”

“In addition to the board moving faster, the player would also benefit from the board being able to rotate at the same pace, if not faster. A faster rate of spin on the board would mean less time for the player to think about the direction and focus more on leading the ball somewhere. With how slowly the board rotated, it felt more like I was waiting longer than I should’ve?”

Additional Ideas

“Have a mechanic designed to never have the player lose track of where the ball is. Options for this would be an arrow pointing directly at the ball, or have the camera kinda zoom out when the ball is moving further away. This is just so that players don’t lose the ball within the maze-like levels.”

“I think you could also Frankenstein another arcade game to it and have Breakout sections of levels that you need to shoot the ball at to get into. Also maybe a special type of coin that slowly disappears the closer the player gets to it, so they’d have to line up a perfect shot from far away in order to get it. Another idea could be a different type of enemy that throws itself at the player and they’d have to shoot it with the ball or something.”

Overall, I feel that I have learnt many skills which will allow me to make a better game in the future. Stay tuned for the next project.

Hey! Its been a little while! I have been gathering feedback from fellow classmates on things that they enjoyed about the game, things that could be improved, and things to consider adding. Before I jump into that though I want to talk about my overall experience with making this game. 

I have learnt a lot about being a game designer during this small production, with many aspects to consider. In Chapter 1 of Game Design Workshop, Fullerton describes the game designers role as someone who “creates the objectives, rules and procedures... a compelling experience”. With this in mind, my first task was to understand what I wanted to achieve from the game and what the players were to achieve from the game. My goal was to not only successfully complete a level of a game, but also create an immersive experience for the player. I had to consider many aspects going into the development, such as: time restraints, my skills, G develops capabilities and criteria requirements. It was important for me to realise these before starting the project so that I didn’t end up making something that was impossible to do.

In terms of creating an immersive game for the player, I wanted to “advocate for the player” (Fullerton, T. 2018). I not only wanted the game to be new and exciting, but I also wanted there to be sensual aspects to further that immersion. I had a friend make ambience music to put behind the game and sound effects when the ball bounced from: the platforms, player platform, coins and spikes. After naming my game PipeLine, I wanted to incorporate pipes into the setting. Though, the art wasn't quite what I initially envisioned, I still turned out to be something I am proud of. I created all of the art using Krita and my Wacom Intuos Tablet, which was a learning experience in itself. 

Playtesting post coming up and final results. Stay Tuned.

Music Acknowledgements: Alexander King Music

Fullerton, Tracy. Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition, CRC Press LLC, 2018. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/qut/detail.action?docID=5477698.

Name: PipeLine

Brief Description: Inspired by Pong and Pinball, this platform game requires the player to manoeuvre a ball throughout the course and collect all the rewards. By doing so, the player will then progress to the next level. However, players must avoid all spikes placed around the course, with only three lives up their sleeve per level.

Genre: Arcade

Primary Mechanics: Arrows to control the direction of movement, A and D to rotate player platform, W to spin platform

Setting/style: Abstract setting with florescent glowing elements in front of a dark mystical background. Ambient themed music and sound effects to compliment setting.

Audience/Demographics: According to earnest.com, today “younger people, especially those aged 18-24, are more likely to make video game-related purchases than older individuals.” However, “many experts agree that the arcade era occurred from the late 1970s to the mid-1980s” (rarehistoricalphotos.com). The target audience for this game are those who enjoy arcade games, or seek to experience this genre. It can be expected that people who played arcade games during the peak era will be more interested in this game verse those who didn’t.

Selling Points: The unique concept of taking classic arcade games and creating a new game. Embark familiarity and spark nostalgia from past players. Captivating colour choices, enticing ambient music, catches attention. 

Sources:

Morris, P. C. (2020). Video Game Demographics. Earnest.  https://www.earnest.com/blog/the-demographics-of-video-gaming/