tdsgamedesign

[tdsgamedesign]

Playtesting and Pitching Insights

Upon finishing all three prototypes and Assignment 3, I think it safe to say I understand the significance of playtesting (specifically early playtesting) and the skill and usefulness of pitching. In the reading ‘Game Design Workshop: A playcentric approach to creating innovative games’ by Tracy Fullerton, she discusses both playtesting and pitching. Pitching is a skill requiring cohesiveness and conciseness, make the game easy to understand, to the point people with even no experience can follow, like recipe but with the engagement capacity of their favourite show. The pitching we used in this unit was an elevator pitch, one page and one sheet, these are useful and simple ways to convey the details, premise, and concepts of your game without thorough development or planning as they are generally created at the start of the development process. Tracy lists 8 types of pitching materials that are sought after and significant to pitching your game, these are:

Sell Sheet (This is a “short attention span” document that explains your idea as well as the target market. The sell sheet should include: game title, genre, number of players, platform, ship date, two-paragraph description, bullet point list of features, and some game art

Pitch deck (This is the heart of your presentation. It will include a top-level description of your game, key art, trailer or gameplay demo, unique features and selling points and player experience, target audience, comparable games, budget, milestones, and team information.)

Game Demo (Demos can be built in differing degrees of completeness. The important thing is that the publisher can get to evaluate the final gameplay)

Gameplay video or trailer (If you cannot produce a standalone playable demo, then a gameplay video is the next best thing. It is a video file that shows the characters and gameplay. The most credible video will be one created using your game code)

Concept document (This is a brief game design document written without excessive details. Ideal contents include: game story, game mechanics, level design outline, controls, interfaces, art style, music style, feature list, preliminary milestone schedule, and a list of team members with short bios)

Gameplay storyboards (This is concept art that tries to capture the essence of your game. These can be in sketch form or final art or both. Ideal key art includes: character concepts, gameplay in action, and key locations)

Technical design overview (This is a technical design document without excessive details. Ideal contents are: general overview, engine description, tools description, hardware used (development and target), history of code base, and middleware used, if any)

Competitive analysis (This identifies titles you are competing against. It shows that you understand the market and your relative position within it. Ideal contents are: summary of your concept’s market position and reason for success and pro and con descriptions of competitive titles with sales figures, if you can get them)

Fullerton, Tracy. Game Design Workshop : A Playcentric Approach to Creating Innovative Games, CRC Press LLC, 2024 (Chapter 16)

These are all materials she states are vital to setting yourself up for the most successful outcome but are not direct keys to being your pitch being chosen for publishing.

Another aspect that Tracy emphasises on is that prototyping and playtesting should be done as early as possible, and to constantly playtest, evaluate and then iterate on the game until its launch. I have learnt firsthand throughout this unit that it is vital to have this kind of system as it will undoubtedly fix initial miscommunication and gameplay faults. The process we used in this unit follows what Tracy outlines very well: Introduction (Script), Warm-up (Questionnaire), Play session, Discussion of gameplay experience (Survey), Wrap-up. This was the outline for all playtesting in Assignment 3. On a similar note the level or feedback also follows an outline: self-testing (done by yourself and those working on the game), confidants (people you know), strangers, target audience. This outline will really help to determine if the game is turning out as you want or if you’ve completely missed the mark, we had this problem in A3 because we did research into other racing games as opposed games with similar gameplay or core mechanics and having this road of playtesting would help us determine this as early as possible.

It is also very important to take notes during the playtesting and even record the experience (if possible) to rewatch later in case you missed anything during the initial test. Having multiple people taking notes on different aspects also helps you not miss vital points in the test when recording their comments or an event that occurred. Tracy outlined an incredibly useful sheet on pages 379-381 for things the playtest conductor should fill out during and after the test takes place to get the most out of the experience as possible. On another note, it is important for the playtest conductor to remember not to lead the tester to specific answers or solutions and to encourage them to think out loud in order to get the most naïve and pure perspective about your game.

Fullerton, Tracy. Game Design Workshop : A Playcentric Approach to Creating Innovative Games, CRC Press LLC, 2024 (Chapter 9)

Overall, playtesting is vital to all game development and design, while pitching is important when trying to secure publishing, advertising, marketing or investment and is even useful when briefing team members. That’s all for the insights I have learned from the reading and throughout this unit.

That’s all for this post, I am unsure what the next post will be but I’ll see you there :D

[tdsgamedesign]

Assignment 3 Postmortem

Highway to Hell was an interesting and enlightening experience. I was lucky to have the teammates that I did as they were all super helpful and involved throughtout the assignment, it would have been a far harder and more stressful experience otherwise. Highway to Hell was a slight twist on the racing game workshop content which made it a game that required more interesting mechanics, story and visuals in order to substantially differentiate it. This meant we had to work more in depth when it came to differing the gameplay to make the game fun or interesting. This also meant that the playtesting would be incredibly helpful when determining the direction the game would take.

Overall, we were slightly off when it came to assumptions of what would make the gameplay compelling or the game fun.  We focused too greatly on the pickups that we neglected the movement and controls making the game feel sluggish and frustrating. Instead we should have looked into similarly designed games like Crossy Road which is enjoyable due to the reactive movement and fluidity of the player model, simiarly the enemies in Crossy Road never simply appear, the player will always have ample opportunity to avoid being squished. These are 2 aspects we didn’t look into when designing our racing game that would have made the experiencee far more enjoyable. I will most definitely do more research into games with similar gameplay as oppposed to genre in the future to hopefully avoid similarly incidents.

Another thing I will be taking away from this experience is the timing of playtesting, had we conducted playtesting a little earlier we would have had more time to fix some of the reoccurring issues in version 1.0. Unfortunately, we did not and therefore only had time to fix smaller things, that did effect gameplay experiences but did not greatly impact overall scoring in the final surveys.For example, the movement and controls I mentioned earlier could have been avoided had we had outside insight from the get go. For future games I will definitely work to get people playtesting as soon as the game is functioning as it will weed out significant issues early so that time is not an issue.

The templates provided were incredibly useful and had recommendations for questions and points of interest I wouldn’t have thought of myself. In the end I am grateful for this unit and its opportunities because I will definitely be taking much of what I have learnt here into future units and game development and design.

That’s all for this postmortem for Assignment 3. The next post will be my current insights to the importance of pitching and playtesting. I’ll see you there :D.

[tdsgamedesign]

Assignment 3 Playtesting for version 1.1 and Changes for future versions

We had 5 playtesters for version 1.1. The issues in this version were very clearly linked to 3 aspects: Speed, Movement and Score. The speed of the enemy cars, and other objects persisted into this version of the game. Players also continued to struggle with the reactivity of the player car making it feel sluggish. Additionally, the score felt unimportant and this effected the gameplay. Other problems were also identified however, they were not as significant to the immersion, fun or gameplay.

For starters to address the frustration with the movement of the player car, we would change to a lane-to-lane movement, increase the turning speed, decrease the turning circle size and up the pps for the (left, right) forces to the neighbouring lanes. The car would move from the current lane to either of the neighbouring lanes with a tap of the corresponding arrow keys. To ensure visual cohesiveness all objects would be adjusted to only spawn in the centre of the lanes.  

Next to address the obsolescence of the score we would add visual cues to the text object such as changing the colour of the score based on the players current level and to zoom and bold the text every 100 points. With the addition of better themed sprites, like flames. Another aspect would be to change the spawn mechanic of pickups from timed to scored so a gun, nitro, etc, will only spawn every 250 or 500 points to encourage strategy. Making a lot of aspects score based will make more levels, end game and bosses easier to anticipate and implement. Similarly, it will encourage players to avoid spikes, and potentially risk using nitro.  

For version 1.1 Nitro stopped working, the timer was not correctly integrated into the new version so instead of the car speeding up when in contact with the nitro, it would occur at varying times after the collision. To fix this we would reinstate the timers and nitro code correctly, to incorporate collision and all other assets appropriately. Likewise with nitro adjusting the sprite slightly to differ it from a water bottle or health pickup would help to differentiate it from other pickups. To create further understanding of the nitro, adding a brief screen in the tutorial describing the game and highlighting that the player is racing against other cars would help players differentiate the speeds better. Likewise, adjusting the speed in the odometer to also have a visual effect when changing speeds would help as well.

A tutorial level will have to be added to demonstrate to the player all aspects of the game to prepare them accordingly. It would include, controls, pick-ups, score, odometer (speed), hearts, brief description of the game, levels, boss fights, enemies and obstacles. This would help to address almost all initial confusion with most of the game aspects.  

Enemy car and obstacle spawn rates would need to be altered to ensure players have room to maneuverer around them in earlier levels to help with creating a skill developing gameplay structure. For example, slower cars, one car per lane in levels 1 to 5, increase speed levels 5 to 10, start adding the chance for more than one car per lane for 15+, etc. This would help to build the players skill, engagement, challenge and flow. Invincibility frames will also be added to ensure a limited time of protection from enemy cars to give the player time to recover Similarly, for the stationary cars (fast approaching cars) a warning symbol should flash in the corresponding lane moments before the car arrives.  This also helps with the learning curve of the game so it's not so hard at the start and then becomes stale later. 

The low severity findings like audios and sprite positioning are not hard to alter. Add audio cues for collision with obstacles, levels, cars, and pick-ups to help communication with the player. Add background noise for immersion. Swap Heart sprites and bullet sprites.

Other pick-ups, obstacles and enemies are to be added as well for more diversity, for example a heath pick-up in the form of wrench that can only be picked up as a potential drop from an enemy car that has been shot. Ramps so the player car can ‘jump’ over incoming enemy cars or obstacles. Potholes that have the potential to force a lane switch when hit. Boss fights, where the player car must shoot at a monster truck, tank etc and avoid bullets and other obstacles from the boss (gun spawns will become timed). This will create more diverse gameplay with more strategy potential. Eventually, the game will end after the player has accumulated a significant number of points (current number unidentified) and escaped hell.  

That is all for this post on the playtest feedback for version 1.1 and changes for future versions. The next post will be the postmortem for Highway to Hell :D.

[tdsgamedesign]

Assignment 3 Playtesting for version 1.0 and Iteration

This during the last few weeks we conducted playtesting; we had 4 play testers for version 1.0. It was a very enlightening and helpful experience as it really helped identify issues with visual and audio communication and game difficulty related to object spawns, speed and the player car.

The playtesters struggled with figuring out controls and understanding the pickups. Many assumed WASD and space controls as opposed to Arrow keys and left click. The effects of the pickups were not always obvious for example, the nitro was assumed to be a health pickup, the spikes assumed dangerous or used in a helpful capacity and gun was assumed with limited ammunition not timed.

Most playtesters struggled throughout the game due to enemy car spawns, object speeds and the hitbox and reactivity of the player car. The hitbox was a larger than the car sprite was visually causing confusion and frustration when players were hit when they thought they wouldn’t be. Similarly, the speed at which the player car moved as opposed to the speed at which the player reacted was not as fast as the player anticipated and this led to a lot of frustration, because while the player reacted in time to a threat the car did not move out of the way in time to avoid it. On another note, stationary cars (fast cars, right 2 lanes) moved faster than the player could react, which led to them losing a life, making the nitro a pickup to be avoided and the spikes sought after. Lastly, the spawn mechanic for the enemy cars was set to randomised timer making it so cars could spawn in whatever lane in a close time. This led to cars trapping the player or the player losing lives in rapid succession.

As an attempt to fix or lessen the confusion and frustration with these aspects we iterated upon the game. To start with we fixed the spawn rate of cars so only one car could spawn per lane. The gun mechanic was also adjusted to be a limited resource (5 bullets) as opposed to timed, this was also in addition to bullet sprites to visual show the number bullets available. To help players now their speed and how it is affected by nitro and spikes an odometer was also added. This is all that was implemented for version 1.1.

Thats all for this post :D, the next post will go over the playtest findings for version 1.1.

[tdsgamedesign]

Game discussion: Quarantine Zone: The Last Check

Recently Brigada Games released the 4th demo for Quarantine Zone: The Last Check. I played the demo for 2 hours until I reached the end. Quarantine Zone: The Last Check, ‘Papers, Please meets zombie apocalypse. Command the last blockade, inspect survivors, and decide their fate: trust, quarantine, or liquidate. Expand your base, upgrade defenses, and fend off hordes. Every step shapes humanity’s survival. Your choice matters and every mistake costs a life.’ The most engaging aspect of the game to me was the checking of infected, sick and healthy survivors attempting to enter the safe zone. Over the week the player obtains numerous items to assist in determining whether a survivor is infected:

Ultraviolet scanner (allows the player to see beneath clothing that could be used to hide symptoms) and see zombie remnants (bites, touches)

Stethoscope (to listen to a survivor breathing)

Temperature and pulse monitor (see the temp and pulse of a survivor)

Blood test gun (determine if a survivor is infected (expensive)

I had a real problem when it came to using the stethoscope, breathing is described as normal, sick breath or infected breath, however due to a sufficient visual or audio example on what either sounded like I confused quite a bit of breathing which led to a few survivor deaths and infected in quarantine. The rest of the items worked well and were easy to use.

Another aspect of the game was the resource management of the survivor’s block, the player purchased and distributed food, fuel and medical supplies as well as upgrading or building new tents, med bays, generators or towers. The only problem I had with this aspect was the confusing fuel consumption and required fuel aspect when it came to distributing power to buildings.

The last introduced aspect of the game was controlling the drone and warding off zombies, I found this to be the most confusing part of the game as the numerous weapons, upgrades and the inadequate identification of where the ammunition was landing caused quite a bit of confusion and frustration. Overall, I believe this section would benefit from a rework or a more strategic gameplay as opposed to hit them all as fast and hard as you can.

The sensitivity of the mouse is unfortunately not adjustable in this version of the game, which takes some getting used to. However, the physics of the game are quite enjoyable and entertaining, specifically the cart and moving of materials.

I believe this came could quite easily be implemented into VR and would be a popular game; however, the resource management may need to be changed slightly to accommodate. The survivor inspection though would be quite the experience in VR, and I think many would like to see it.

Overall, I am interested in the final product of this game and will continue to monitor its progress. That’s all for this post and the next one will definitely be about the versions 1.0, 1.1 and playtesting of Assignment 3.

[tdsgamedesign]

Game Discussion: Poppy Playtime

In this post I wish to discuss the video game franchise Poppy Playtime. Poppy Playtime for those unfamiliar is an episodic survival horror video game series first developed and published in 2021 by American indie developer Mob Entertainment. The game is set in an abandoned factory owned by the fictional toy company Playtime Co. The player controls a former employee who receives a letter inviting them back to the factory years after the company's staff mysteriously disappeared. This post will likely contain slight spoilers for the games but will mostly focus on the game design elements, mechanics and aspects that I think Mob Entertainment did will, not well and how they can improve.

I believe Chapter 1 “A Tight Squeeze” is their best chapter by far as it contains only their strengths, which in my opinion are atmosphere, environmental and direct storytelling, and chase sequences. The chapter includes the games most iconic antagonist, Huggy Wuggy, numerous VHS tapes, and a creepy, tension thick atmosphere in the first level of the abandoned factory. The VHS tapes are relatively easy to obtain and do not hinder the flow of the level greatly with the time needed to watch. They are not overly obvious with their lore implications which makes them entertaining and engaging for players leaving them with questions that they will gain answers to as the game progresses. The atmosphere in chapter 1 is phenomenal, it uses great timing, distraction, unassuming areas and a look of abandonment to leave the player nervous and unassuming at the beginning, only to increase tension and nervousness until the chase sequence at the end. An example of this is when the player returns from a separate room to the main lobby after being distracted with other room mechanics to find Huggy Wuggy missing from his platform, the player then continues through rooms waiting for the inevitable until Huggy appears before them as they attempt to leave. The game’s best chase sequence occurs at the end of the chapter when the player is chased through the conveyor belt system, ending with the Huggy Wuggy falling off an incredibly high bridge. This chance sequence is so impactful due to the pressure and tension built throughout the chapter, the enclosed and winding conveyor belt system and the use of code to keep Huggy Wuggy at a certain distance unless significant errors are made, causing a jumpscare and the player to return to the last checkpoint. The player ends when the find the games namesake Poppy Playtime trapped in a box deeper within the facility.

Chapter 2 “Fly in a Web” is most fans favourite chapter as it ups the tension and expands upon the lore and story without straying far from the 1st chapters atmosphere and environment. This chapter also contains numerous VHS tapes with the same lore importance and flow balance as the first chapter. The atmosphere turns more ominous in the second Chapter as the main antagonist Mommy Long Legs not only speaks but is also very upfront about her hatred and bloodlust for the player. Similarly, her voice lines convey significant amounts of story related to the factory and the player. The main environment the Game Station a place said to be many children’s joys is also abandoned and littered with remnants of their existence. Mommy Long Legs sets up tests for the player to complete before she will allow them to leave however, she rigged the last game and becomes enraged as the player cheats it to survive. This leads to the second chase sequence in the game. This chapter only struggles slightly in its environmental communication for the direction the player must follow to continue the game. This is most significant in the chase sequence against Mommy Long Legs as the player moves back and forth through multiple areas, but the direction is changed each time, and the only indicator is small almost transparent spider webs. This caused quite a bit of confusion for most players and prompted them to start the section again. However, it is still a thrilling and tension high sequence that ends in Mommys’ demise. Upon defeating Mommy Longs Legs and glimpsing the games main antagonist for the first time, the player moves to escape the factory through the game station train however, Poppy Playtime has use for the player yet and they are moved deeper into the factory.

Chapter 3 “Deep Sleep” the atmosphere becomes more ominous and chilling in this chapter as we are brought to Playtime Cos (deep) underground orphanage, again abandoned and some parts destroyed. This chapter more than doubles the previous chapters play lengths as the content and story are significantly longer and with the addition of a bigger and more free roam able level. Unfortunately, while this chapter’s atmosphere is darker than the previous chapters it falls off in some playthroughs as it misses opportunities to create its tension through cutscenes, more directed and communicated level design and visuals. This chapter’s main antagonist is Catnap, who is said to watch and stalk its prey (in this case the player), Catnap appears in the shadows of each playthrough since the beginning however, many players miss these moments as the area is either to dark or the scene should have had a controlled camera. The most significant moment I have seen this occur with is when the player is in the dream state in the orphanages ‘Home Sweet Home’, the player picks up the phone and this chapter’s new ‘ally’ says run, prompting the player to turn towards the door and hopefully see Catnap lurking from beyond its frame. However, because the turn is player controlled some players miss the scare entirely which causes confusion and frustration later in the game as they do not understand or feel Catnaps influence throughout the chapter. Another let down this chapter that led to player frustration and confusion was the lack of flow when it came to move between the sections of the game as well as environmental direction many players felt lost or turned around throughout the chapter. This could have been remedy through use of white paint which they use at some points in the chapter simply to help guide the player. Lastly, and what I believe is most players disappointment with this chapter was the Catnap boss fight as opposed to chase sequence. As I stated earlier Mob Entertainment succeeded greatly with the chases and unfortunately this boos fight did not live up to a good replacement. The fight was confusing, overwhelming and frustrating to most players, as to some due to stalking issues I mentioned earlier were confused as to why Catnap was attacking in the first place. Most players did not understand the mechanics, or the balancing required to complete the boss fight and overall, it took most far longer than intended to complete and was huge letdown. Upon defeating Catnap, they player then learns of why the factory was abandoned and moves deeper into the factory.

Chapter 4 “Safe Haven” was the chapter released this year and while it was lore and story heavy however, some issues that arose in chapter 3 reoccurred here, but most were a least attempted to fix. Mainly the boss fights and directional environment communication. However, I will mention that this is the first chapter where there were many complaints that VHS lore tapes were too hard to acquire and took too long which ruined the flow and immersion. To start the atmosphere in the chapter was dark and suffocating at the beginning and end of the chapter while also keeping it tense throughout which was beneficial to the tone of the chapter. They did this be remedying what happened in the second chapter by adding cutscenes, fixing lighting issues and keeping the environment relatively cohesive. The directional communication was better this chapter as they utilised the white paint, narrow and confined areas and obvious visual blockades to guide the player. However, some sections of the chapter still had issues with navigation due to vision obscurity that was used to challenge the player. Similarly, another mechanic was added to this chapter which lead to the design of some levels being overly complicated and overwhelming. Lastly, this chapter contained two boss fight one for the chapter’s main antagonist ‘The Doctor’ and from our ally turned enemy ‘Doey’. It was quite obvious that Mob Entertainment attempted to learn from their Catnap boss fight by incorporating chase like sequences into both boss fights as both boss fights required the player to keep sprinting and moving to avoid damage or jumpscares. However, this seemed to overwhelm a lot of players causing the boss fights to feel “clunky” and “unorganised” due to rashness and repetitiveness. This chapter did incorporate one pure chase sequence with Doey before their boss fight and many players felt it did the previous Huggy and Mommy sequences justice. In my opinion the tensest and most well-built atmosphere occurs during the end of chapter 4 when the player is enlightened to numerous pivotal lore and story points and is confronted at the end of the chapter. This leaves me excited for the last Chapter and with the attempts from Mob Entertainment to remedy past chapter issues I believe they will continue to work to improve.

Lastly, a complaint I see a lot when it comes to Poppy Playtime is an issue that spans across all chapters as it ties directly to the moment-to-moment gameplay. This is the grab-pack the players only item and what the player uses to traverse Playtime Co. It has numerous hands with multiple abilities for example:

Blue Hand – Unlocks blue hand scanners, conducts electricity and moves some objects

Red Hand – Torch, unlocks red hand scanners, conducts electricity and moves some objects

Green Hand – Stores and transports electricity

Purple Hand – Used on purple jump pads

Orange Hand – Shoots flares

The Omni Hand – Unlocks high security doors

All these hands are obtained and some lost throughout the chapters and they are the mechanics used to complete puzzles. However, many players feel these puzzles do not fit into the Playtime Co environment or story as these hands were only used by employees. Similarly, the hands have incredibly slow switching animations which frustrated players in the Catnap boss fight as multiple hands were required in quick succession. Likewise, these puzzles tended to detach players from the story as it distracted them from there surroundings. The most disliked hand mechanics come from the purple hand and the swinging ability. Many players felt the addition of the purple hand and additional mechanic were redundant to the gameplay and only wasted time. While the swinging mechanic feels unintuitive to some players and the physics feel off putting or strange.

Ill wrap up this post here, the next one will either be an update to Assignment 3 or my opinion on the demo game Quarantine Zone that I played this week. See you there :D.

[tdsgamedesign]

Assignment 3 Development Progress 

This week we aimed to have the discussed version of Highway to Hell ready for playtesting this meant getting:

All sprites

Enemy Cars

Nitro (speed boost), Gun (enemy car destroyer), Spikes (speed loss)

Start Scene, Game Over Scene, Level 1, Level 2

Score, Time, Health

All complete and functioning. I was tasked with implementing the Nitro, Score, Time, Health, Start Scene and Game Over scene. I was also in charge of compiling the other team members work into one (my) version of the game. So, I started by using the code I used from my racing game. The following code sets up all the current timers, variables and health for the start of the level.

This next code was used to determine whether a nitro boost would spawn the base speed (Nitro2 = 1), and to ensure no overlap with the other cars in the scene.

The next code is what I used to control how the speed worked when the player collided with a nitro can (Nirto2 = 2) or spike (Nitro2 = 3).

The following code was the health system for the player car.

And this code was for the timer.

Finally, this is the prototype Start Scene, as it still requires a background sprite to make it look more inviting.

And this is the Game Over scene we as a team have yet to decide if it needs anything else but for now it will remain as is.

The next steps are too fully implement the gun system, level 2, potentially more fluency between all the scenes.

What has been and is soon to be implemented I believe will be the fundamental aspects of the game which will impact the moment-to-moment gameplay and overall tone of the game. Which means they are the most important parts to be playtested as they are the most significant parts of the player experience for this game.

That’s all for this post on the progress of our Highway to Hell, the next post will show the final protype and address the playtesting :D.

[tdsgamedesign]

Group Formation and Assignment 3 Team Discussion

The next assignment is a group assignment. As of the workshop in week 9 my group was formed, we are a group of 4 (Tamsyn Douglas, Nathan Cribb, Benjamin Jamroz, Yixuan Tang). To start working towards the Assignment 3 Part A submission we discussed whose assignment 2 to use and started on the Part A document. Upon looking through the all the team members A2 one page and one sheet we decided that the best game to continue development and playtesting on would be Highway to Hell.

Highway to Hell is a top-down racing game, where the player races against other cars while avoiding crashing into the cars and other obstacles. The highway is littered with speed boosts and other items the player can utilise.

After confirming that Highway to Hell would be the game that was used, we got to finishing the Part A document, which consisted of the plans regarding development, and playtesting. This was soon finished, and we continued development of the game.

The next post will go into depth on the development of Highway to Hell, see you there. :D

[tdsgamedesign]

Assignment 2 Done!

I have finished assignment 2 and here are the results.

If I were to do this assignment again I would design the One Page in a better product for A3 size documents as ppt was sufficent, I feel I could have had better luck with space if it was larger.

Likewise, I would either create my on writing (drawing) or use a font that could be read by the pdf editor so that the project could be immediately saved as a pdf instead of having to do a rather annoying work around (screen shot into a word doc).

In regards to creating a more interesting game, I would start by upgrading the quailty of the art, then I would do many rounds of playtesting to ensure that all aspects of the game work, if not I will have to look into the code and fix them. I would also have to create a Start, Game Over, and Level screen. The level screen would be made so the player can go back to levels previously attempted. Numerous other levels would also have to be designed to make the game longer and more engaging.

Similarly, I would try and give the player more choice in regards to abilities, looks etc. to give the player more control and help the player feel more immersed. This could be done by implementing a Lizard-Frog-Mouse component or Intransitive or Transitive relationships in connection to the abilities, to help balance the game.

That’s all for this post. The next post will most likely be in regard to assessment 3, so see you there. :D

[tdsgamedesign]

Assignment 2 progress

Assignment 2 requires us to pick one of our prototypes and create a detailed One Page and One Sheet for it.

The readings (Game Design Workshop) Chapter 14 discuss communicating game designs. The subpoints Visualisation, Flowcharts and Description I believe will be the most useful when attempting to complete Assignment 2. The subpoints discuss how different perspectives and game aspects can be netter represented visual (Useful for the One-Page and One-Sheet), and how flowcharts help to communicate the inner processes of the gameplay (Useful for One-Page). And lastly, clear and concise text can help to communicate specifics that visual cues cannot (Useful for the One-Page and One-Sheet).

A One Sheet is an should be an attractive, single sided, A4 document that could be handed to individuals interested in helping to develop the game. Whereas a One Page is a poster-sized document that is customized to the game, and the style of the designer. The goal is to be a reference tool that team members can glance at and know what to build or iterate upon.

I have decided to use the Platformer Prototype for assignment 2s, One Page One Sheet.

I created a background image for the One Sheet and then I planned out roughly where the information on my One Page would go. As seen below.

The plan with the background was to get as many features in the current game as possible without overcrowding it, as text will also need to be placed.

Next, I started to address all dot-pointed criteria on the CRA by writing out all answers to the prompts, as seen below.

This will not be all that I will do but I think it is a good start. All I have to do now is transport information onto the pages and make it look presentable. That’s all for this post and I will post again with the finished products. :D

[tdsgamedesign]

Racing Game Feedback and Postmortem

Over the past week I have had numerous people play my racing game. The results of this are as follows:

Comments (my additions)

Good

Sprites (not player office)

Controls

Boosts (coffee, switch)

Concept

Improvement

Random generation has some overlapping issues (specifically with office sprites)

An indication or more obvious visual representation of the player office (objective)

Better visual representation when colliding with boosts and offices (to supply better positive and negative feedback)

More variety of boosts, and make them scarcer

Bad

Timer does not stay in the camera view of the player

Boundaries do not currently contain the player

Other

Generation of the level / game varies greatly in time and can leave the level as a black screen and never load.

As I have previously, I will explain how I plan to address the aspects within the improvement and bad sections.

I believe the issue of the random generation has to do with the current loop (repeat) function I have, I will need to look into this function more to understand is better. Hopefully this will help me understand how to better structure this function so it addresses all offices present as opposed to the one that has just been placed (I suspect it will need a While function).

The reading (Game Design Workshop) focuses heavily on the importance of feedback (pages 195-198) either visually or audibly and there ability to influence the gameplay and player engagement. To create better feedback more sprites will need to be designed and created. I will most likely add particles and/or a camera border effect for the boosts. And a ‘tracker’ or different coloured office to better show the player office.

To make boosts scarcer the repeat function will simply need to be repeated less. More boosts will just require more designs, implementation and research.

The timer issue I believe is tied to the fact that the current camera that follows the player is a behaviour and not coded. I will change this, and it will hopefully fix this problem. Similarly, the boundaries contain platform behaviours and not code so I will do the same with these.

I am currently unaware what the issue is with the loading of the level, but I will do some research to see if it something I can fix or if it is a processing issue.

That’s all for this post, I will most likely not do an iteration post, but you never know. :D

[tdsgamedesign]

Racing Game Development

To start I created sprites for the player (Idle, moving), office and player office.

Next, I added the rotation for the animation (W, WA, WD, A, D, S, SA, SD).

Next, I started working on having the player and the player office spawn once at a random location within 2000, 2000. Then I ensured that they couldn’t spawn within 500 pixels of each other. The next step was to have numerous other offices spawn randomly, without overlapping anything else. The coffee pot was similarly added to spawn randomly around the map without collision, however it was to spawn further apart then the offices and insignificantly less numbers.

Then a timer was added to the top left of the camera that followed the player character, this was to show the player their current time.

Next, I added numerous conditions involving collisions. First a win condition that would occur when the player collided with the player office, then an add 10 seconds to the timer when in collision with another office and finally a speed change from 200 to 500 for 4 seconds when in collision with a coffee pot. Lastly borders were added around the edges of what I wanted the map to be to confine the player into the game space.

In the reading (Game Design Workshop) it is discussed how obstacles are a common form of conflict and for this game specifically in the singleplayer these obstacles are going to be the most significant challenges the player faces.

The next steps for this game are to add a start and end screen, and exit/close game button. Functionality to the randomise object (when in collision with player, the map is reloaded therefore randomising it again). And multiplayer functionality (possible customisation to differentiate players).

That’s all for this development post. I may make a post on adding the components of the previous paragraph if I get around to completing them. :D

[tdsgamedesign]

Racing Game Pitch

The third prototype for the unit is a Racing game. In my opinion a racing is getting from point A to point B as fast as possible, so that is going to be the premise of racing in my game. Another aspect I would like to incorporate is randomness, having the player actively search or think to succeed. Lastly, from my experience racing games are the most fun when you play with other people, so I would like the game to be able to support multiplayer.

Elevator Pitch Title: Wheeling Office

'You’re late for work but can you make it too your desk before the boss finds out? Race around the floor and avoid other office spaces and the occasional manager to keep your time down. Be on the lookout for a caffeine boost from a coffee pot and other helpful powerups on your way. Invite friends to race against and see who’s the fastest on a wheelie chair.'

Game Controls – WASD (to move around the level)

Unique Selling Points

Random – The player, player office and office spaces will randomly spawn around the level, ensuring a unique run every game.

Multiplayer or Singleplayer – Have a choice in playing solo or competing with other players.

Timed but not restrictive – Where some games count down on a timer this one counts up to give the player a sense of urgency but not frustration.

The audience for this game is going to be people who enjoy speed running, and competitive multiplayer experiences.

The readings mention on page 570 that racing typically take the form of an arcade style or racing simulator. Of the two this game does fit more with arcade style; however, I believe the implementation of competitive multiplayer and a free roam track more the game away from the traditional arcade style racing games. I think this is beneficial and interesting as it is not a type of game I see often.

That’s the basis for my racing game prototype the next post will be the development post for this game. See you there :D

[tdsgamedesign]

Asteroid Feedback and Postmortem

During the Workshop and rest of the week I had quite a few people from varying levels of game design knowledge playtest my asteroids game. The feedback form was the same as the form used for the platformer, so I'll jump right into addressing the concerns.

There was quite a bit of feedback regarding the speed of the bullets and speed of the asteroids. The current speed of the bullets (400) made the shooting feel delayed and in turn didn’t make the gameplay very engaging or fulfilling. Similarly, the asteroids didn’t feel like much of a challenge due to there speed (50-60). This didn’t make the asteroids feel like much of a challenge and didn’t contribute to the engagement level. This impacts the balancing (389-390, Game Design Workshop) of the game as it doesn't meet the goal set for the player experience. To remedy this, I’ll change the bullet speed to 1000 and up the spawn speed to 70 and rebound speed to 80. This will hopefully help to have the player more content and engaged.

Another issue I identified while watching and with feedback was the Power-ups, most players avoided them when they spawned, and this was because the players assumed that all objects that spawned from the top of the level were “enemies”. The plan to address this is to have the power-ups spawn on platforms, this will also encourage the players to protect the platforms and move around the level to collect them.

Lastly, during playtesting a bug was identified that involved the asteroid speed and direction. When asteroids hit the boundaries or platforms, they have a chance to increase their speed and continue in that direction as opposed to rebounding. I am currently unaware why this occurs; however, the recommendation is to apply Physics 2.0 behaviours to the asteroids, so this issue doesn’t persist and so the rebounds act more realistically.

It would be quite easy to iterate the first part of the feedback however, I would need to look into Physic 2.0 to implement it. If I do end up iterating all the feedback, I’ll upload a post about it. Well, that’s all for this post see you in the next one :D.  

[tdsgamedesign]

Asteroid Development

For starters I added all the sprites and tiles I would need for the level this included, the ship (Player), the breakout tiles (platform), and asteroids (enemy), lives and score. The next part was to develop the controls, WASD, having the player ship turn towards the mouse position, and left click creating the bullet.

The bullet had to be optimized by making sure it wasn’t a laser (added timer, trigger once), and moved the creation point of the bullet to the front point of the player ship.

The asteroids were developed next, 3 sizes of asteroids were created (large, medium and small), and to utilise all 3 of the animations for each size Random() was used and it was also used to control where the asteroids spawned in on the level. I made this section of the level the top (Random(1150), Random(10)) and had the asteroids move at a random angle towards the bottom of the level (where the player is). To ensure that asteroids spawn in a timely manner a timer and trigger once was added. I also added collision mechanics between the asteroids and the platforms, so the platforms are destroyed, and the asteroids are redirected.

Next Lives, Damage and Score was implemented, I used text objects to contain the information for the player lives and score and Global Variables to hold values and change the displayed text. Large asteroids do take 2 lives from the player and medium and small asteroids take 1 life.

Next, I added 2 other scenes to the game, a Game Over scene and a Start Game. Both scenes contain buttons (Start, Quit, Restart). The Game Over scene is used when the players lives are less than or equal to 0 (aka when hit with numerous asteroids or falling into the void). And the Start Game scene is used upon start up to give the player choice (play or quit).

Lastly, I attempted to add the powerups, Extra Life and Triple Bullets. I did this by trying to determine which powerup to give based on which animation was created which is randomised between red and green (Red (life), Green (bullets)). These spawns are timed and are only triggered once per the time. However, while the player can collect the powerups and they spawn when their supposed too, the effects added aren’t working. I believe this is due the code I am using so I will continue to try and remedy this through experimentation with For All and While statements.

On pages 105-106 of the Game Design Workshop reading, it discusses objectives in games and how they can impact the tone of the game. For this version of the game, I plan to have only one objective; obtain the highest score. This I believe impacts the tone of the game to be more serious and competitive. I think this tone compliments the game greatly as it influences the player to engage in the specific acts of survival as well as destruction of the asteroids.

That’s all for this post the next post will go over playtesting and feedback. :D

[tdsgamedesign]

Asteroid-Style Project

The next game to be designed in GDevelop is an Asteroid-style game. However, we were told to think about what the core mechanics, style, or themes are and to try to apply them in different ways. In my opinion the core mechanics of Asteroid are destroy and evade, destroy the asteroids or avoid being hit by them to continue playing. The style is generally pixelated and/or simplistic, common for older games as they did not have the understanding or technology to make it more in depth. And the theme is around space, spaceships, aliens, asteroids. The mention of Asteroids got me thinking about other older, simplistic games and the one that came to mind the most was Breakout. The objective of Breakout is to destroy all the platforms without losing your ball, but what if it was flipped what of your objective was to stop the ball from breaking the platforms. And that is the basis for my Asteroid-style game.

Elevator Pitch

‘Stopping a Breakout’

‘Stopping a Breakout is a combination of 2 simple yet iconic arcade games, Asteroid and Breakout. The player must destroy asteroids to either stop themselves losing a life or to stop the asteroids from destroying the platforms that keep the player alive. The player should evade asteroids and missing platforms to stay alive as long as possible and destroy as many asteroids as they can to gain points. To spice things up power-ups will fall to assist the player like, multiple bullets or lives. How high do you think you can score?’

The game is to be played with WASD keys and platformer behaviours for the player, so the player can move across the breakable platformers. The mouse controls the direction of the player model, and the left mouse key controls buttons and bullets.

3 unique selling points for this game in my opinion are:

Simplistic: The game has simple concepts, WASD and Mouse, shoot, destroy and evade. The visuals are also not overwhelming.

Neverending: The game has no win condition so as long as the player doesn’t die, they can continue to play.

Nostalgic: A lot of older games are heavily pixelated, and Breakout and Asteroid are some of the most popular 70s games ever made. For those games most people have played them and if they haven’t there easy to obtain and understand.

The audience for this game would be those who enjoy simplistic 2D platform shooter.

This is just the idealisation for this game, the next post will be about the development of this project. See you there :D

[tdsgamedesign]

Platformer Playtesting, Feedback and Postmortem

In this post I will go over the significance of playtesting as outlined in the course and in Game Design Workshop by Tracy Fullerton. Chapter 9 of the textbook addresses playtesting and states it should occur throughout the development and design process. Tracy Fullerton also states that playtesting is something a designer performs to gain insight into how players experience the game, and to understand if the game is functioning the way the designer intended.

In the week 4 workshop we were instructed to have others playtest our platformer prototype. The image below is the feedback sheet my play-testers have filled out.

I will go through a basic summary of things my play-testers thought the game did relatively well at and aspects they think I can improve on. A common point of feedback that I was given was to add more communication through visual and audio cues, so the player better understands the objectives, most significantly the collection of fungi. I plan to add a point system (i.e. stars), an animation and an audio cue for the collection of the fungi. Other communication was idealised and addressed in the “Gameplay Continued” post.

Another common point of feedback was due to the design of the playtesting level and lack of instructions / tutorial the players did not know all the abilities most notably the slow-falling mechanic. When asked how this mechanic could be better implemented the testers said to either add a fall damage aspect or to remove it completely. I am currently more inclined to remove the mechanic, unless I can utilise the mechanic more effectively. A lot of the play testers enjoyed the bounce pad and plunge mechanic. Feedback on the bounce pad was mostly the usefulness and fun that came from using it. Similarly, feedback for the plunge mechanic was that players enjoyed using it to ‘solve’ the puzzle and collect the fungi, aka destroy the ground, however they think the game would benefit greatly from it being also utilised to defeat enemies and if it was also included in a tutorial so that other players know it exists.

For aesthetic feedback I had a few recommendations to change the player avatar so that the game felt more immersive. I had previously attempted to change the avatar to a freely available asset however, the .png files did not work and I was unsuccessful. I will have to re-attempt to change it even if I must create my own.  For the rest of the visuals the feedback was quite positive as they could see the theme or understand what the animation was representing.

It is unlikely that I will have time to iterate the game currently, however if I do have time in the future to, I will upload a post about it. Well, that’s all for this post see you in the next one :D.