jimmy10hands

[jimmy10hands]

A3 Post Mortem + unit reflection

Assignment three was a big learning experience in working collaboratively with a team to create and test a game. There were plenty of things that went well, as well as plenty of things that I've learnt from and can improve on going forwards.

Unfortunately at this stage in the semester, I have fallen behind on some of the final readings suggested as other assignments have taken priority, but have found great value in taking through what I have learnt through the semester.

Overall, I'd call the project a success in that we made a prototype game that was interesting and playable and were able to test it amongst a variety of playtesters for valuable feedback on what worked well, what could be improved and what was missing from the experience. There was lots of positive feedback amongst the suggestions and provided a clear path on where to take the game in future, if we so desire.

In general, our team worked together fairly well throughout this final assessment, and despite some of our disagreements, came together and made things work.

Throughout the semester I learnt a lot about designing, prototyping and the playtesting process throughout the several cycles we undertook, taking in a lot of the knowledge acquired through the readings by Tracy Fullerton and implementing that into how I went about my processes as I experimented with GDevelop.

Thank you to the teaching team for the work they put in to making this unit enjoyable and educational.

[jimmy10hands]

A3 Playtesting

Playtesting at this stage consisted of a few informal plays from friends and family to get basic feedback on the concept and what they'd like to see from the game. The general consensus was that they liked the direction the game was going but that there were a number of things that needed to be included and improved.

One additional playtest of the basic gameplay loop was performed in class where they provided valuable comments as they played.

Initially they were intrigued by the class selection and chose the mage, commenting that intelligence was better.

Upon entering the game, the player was confused on how to play and began to panic as the enemies approached from every direction. They figured out that movement was controlled with WASD but needed help to figure out the attack was mouse controlled, and tried every key on the keyboard before that.

Clearly a control page is required,  and perhaps an alternative mouse control as without a mouse the trackpad is not ideal.

Upon death, they pressed escape and gave the knight class a go. They disliked the close combat variation and were confused as to why someone would pick this over the ranged, as there is no perceivable benefit.

They are right, currently the only change is range vs melee which leaves no argument for the knight being picked but there are a number of changes we plan on making to the classes to make them balanced and distinct including health, damage and possibly movement.

[jimmy10hands]

A3 Dev Post

For A3 part A, our group each sent through their One Page from A2 for us to collectively vote on the one we liked most and felt like we could take further. As a group, we decided on Dungeon Master by member Minh as it seemed the most refined and complete.

The game consisted of a simple asteroids style dungeon rogue-lite where the player could pick from classes and pick up different weapons to clear their way through different stages.

However, Minh didn't communicate much of his game beyond this so we did our best collectively to describe the components of the game that we want completed for a prototype based on the descriptions from his one page and outline how we'll work together.

This included using discord for communication, google drive for sharing our documents and game progress, as well as potential other tools if we found we needed them.

[jimmy10hands]

Racing Post-Mortem

Taking notes from my readings of chapter 9, the playtesting for my racing game Hoppers has gone fairly well. Fullerton highlighted the importance of preparation, selection and analysis, amongst other things, as key aspects to the process.

She includes the below diagram which I found really helped visualise how the iterative process of playtesting should develop your game into a refined point where the changes become smaller and smaller until it's ready to be released.

She goes on to talk about how to go about conducting a playtesting session and how my role now is "... that of an investigator and observer who must give these playtesters access to the game, lead them through a useful playtest, record what they say and do, and, later, analyse their responses." (Fullterton, P281). I went into this playtesting cycle with this mindset and as more of a passive observer and found it to be quite productive.

The method of playtesting for Hoppers was to get two volunteer players to sit down, briefly introduce themselves to each other and then begin figuring out the game together after briefly explaining the keys the each player can press seeing as they were on the same keyboard and a controls screen wasn't yet developed.

All players were very quick to understand the controls and objective and quickly began enjoying the difficulty and competitive nature of the game.

Despite my best efforts, the jumping mechanic still felt a little clunky and this was evident in the players feedback. Overall comments were positive however, and most if not all testers that played the game seemed to enjoy themselves while playing with one another.

Negative player comments and possible future fixes:

The jumping distance was quite hard to gauge as there was no visual indicator as to how far or powerful the jump was.

A simple fix for this would be to implement a bar for each player showing jump power

Sometimes it was too hard to land exactly on the lily pad/it was too strict with sending you back to the start

The area around could be made slightly larger to make the game more forgiving

Even possible difficulty settings to change this

The jumps felt a little off

1 or 2 comments on this despite my best efforts. It was hard for them to pinpoint what felt off but something about the visuals of the frog slowing down may be the problem. Some more work into refining this may be required.

The players were able to visually jump off the map

This wasn't too much of a problem as there are no lily pads out there so the player dies and gets sent back anyway, but as a quality of life feature, stopping it in the first place is an easy fix

Overall I really enjoyed making this game and felt it was relatively successful as a prototype. Additionally, while I wanted to use it for the A2 one sheet and one page, the multiplayer aspect seems to be against the criteria which is unfortunate.

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press

[jimmy10hands]

Racing Development Post

Hoppers has been coming along smoothly and has been quite enjoyable to work on. I also believe the multiplayer element I'm including makes it far more enjoyable to play around with as it invites a more social environment, and from the discussions I've had with friends they seemed to enjoy the non-functional prototype.

As for problems I've encountered during development, there isn't much to include as there haven't been any particularly complex or very new mechanics. The part that has taken me longest so far is getting the frogs to jump in a natural manor depending on how long the spacebar is held, and is still being refined.

Obviously it is a very different take from the racing game given as an example, but from my brainstorming session last week, it was the one that seemed most exciting for me and I'm glad I went with this as I much prefer this version anyway.

[jimmy10hands]

Racing Game Elevator Pitch: Hoppers

Hoppers Elevator Pitch

In chapter 6, Fullerton talks about conceptualization and the development of ideas for the creative process. She talks about how it is not always easy to come up with ideas on demand, and then brings up the topic of brainstorming as a viable and formalized system of idea generation (p172). This is why for this project I utilised brainstorming to formulate the concept of my racing game for this cycle. After several iterations of different idea paths, I decided to go with one that didn't feel like a traditional "car racing" game as what was explored in the demo provided. Below is the elevator pitch for this idea.

Hoppers is a co-op 2 player dash to the finish line! Players will each control a frog with three simple controls: rotate left, rotate right and a jump sending you forwards depending on how long you held it. From the bottom of the screen, each player must jump between a series of lily pads and be the first to make it to the other side where a tasty frog meal is awaiting. Miscalculating a jump and landing in the water between will send the poor little frog swimming back to the bank it started from.

Once the player lands on a lily pad, they have a certain amount of time to leap to the next one (or at least attempt to) before the lily pad sinks under the frogs weight, and again is sent back to the beginning.

Below is a simple diagram of how the game might look:

The controls for this game are very basic as the player only has three things they can do.

For the left player (blue):

A: Rotate Left

D: Rotate Right

W (hold): Jump forwards X distance

For the Right player (red):

Left: Rotate Left

Right: Rotate Right

Up (hold): Jump forwards X distance

Three unique/interesting aspects about Hoppers include:

Not a traditional racing game with cars or other vehicles around a track, more in-line with parkour games whilst retaining the competitive component of a racing game

Same keyboard co-op, which isn't something you see too often anymore. Also potential to have one player be AI controlled if there wasn't a second player to join

Simple controls and concept to learn, but challenging to master the timings and angles needed to get between different lily pads in the most efficient way possible

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press

[jimmy10hands]

Post-mortem: Pivotal

Asteroids Postmortem:

The playtesting for this prototype game went well in that it provided some valuable insights. From the three people to play the game, the general response was positive.

General comments:

Intuitive controls mostly, some felt there might be more somewhere on the keyboard but weren't sure.

The upgrades felt rewarding, although some of them may need to be balanced (Fire rate got exponentially better as it removed a flat rate time between shots, so by the end it was essentially halving it)

With this too, the general consensus was the the ui for the upgrades was okay, but after asking about a separate screen for it, they thought it was a good idea

The enemies could have been more diverse

While this is something I would have loved to add, It wasn't something I got around to including in the playtesting build. I agree in that it would make the game much more exciting

Things to add/change in the future taking playtesting into consideration:

Simple home screen that displays the controls to the players

Complexity to enemies (more types, differences in what they do)

Refined and balanced upgrade screen/system

More unique visuals

In general, I'm happy with how my asteroids game turned out and the direction I took with it. It was influenced by a few other games I've played in the past, including diep.io and Seraphs Last Stand in terms of upgrades/paths and enemies, while the stationary player aspect is more of a tower defence concept. I feel as though this combo worked well, and produced an engaging experience for those that played it. With the consideration of balancing Fullerton talks about and that I looked at in the previous weeks alongside the changes mentioned above, I believe this game would quite enjoyable.

[jimmy10hands]

Development Post: Pivotal

Development Post: Pivotal (Asteroids game)

I've played around with and implemented the basic functionalities of the game, rotating, shooting, enemies that spawn around the screen and move towards the player, damaging enemies, and player health/end condition. Shooting the enemy gives a small amount of points that the player can spend on increasing their fire rate, making it easier to kill the enemies as it continues.

While functional in its key components, the game is still missing a few things to make it more engaging. This includes a more extensive upgrade system and menu to make this process easier, different enemy type for diversity and enemy scaling so the player doesn't quickly outgrow the difficulty.

From feedback of people that have briefly looked at the game, these improvements are desired as they found it quickly went from somewhat challenging to boring and easy as they increased their fire rate in the current build.

Overall, progress is going well and I have some clear goals to aim for.

[jimmy10hands]

Asteroids Elevator Pitch: Pivotal

Title: Pivotal

A game where you're the centre of attention! Placed in the centre of the screen, you as the player have no movement capabilities. With enemies swarming from every side, your job is to fend them off with your small shooter, wave after wave. The upside is that with each enemy you destroy, the more points you earn to spend on various upgrades, experimenting with different builds each playthrough to see how far you can make it.

This time I'm coming into the game with more of an idea of drawing in inspiration from other things from my experience in cycle one and knowledge from the readings.

This game has some influence from games such as Diep.io and Seraph's Last Stand but has the unique tower defence element of not being able to move.

Putting points into one upgrade path will begin to limit the other paths, so maxing everything is not an option and strategy comes into play. I'm going to have to put some more thought into how I balance this aspect as I go into playtesting later, as Fullerton highlights its importance and defines it as "... the process of making sure the game meets the goals you have set for the player experience: that the system is of the scope and complexity you envisioned and that the elements of that system are working together without undesired results." (Fullerton, p321).

Simple diagram of what gameplay might look like

Controls:

The player would control the game mostly with their mouse, pointing around the screen to click on/towards the enemies, although the turret rotation speed will not be as fast, making for slightly more challenge.

Left click to shoot, maybe right click to "pause" so the player can purchase their upgrades. Also considering using escape, but want to keep it simple with just mouse controls.

Unique selling points:

A different take on asteroids, where instead of relying on precise movement and agility to dodge things coming towards you, you simply just focus on shooting back and upgrading yourself to keep up with the increasing difficulty

Upgrade "trees", where upgrading one thing begins to limit the other options, making for different builds and strategy in upgrades

Enemy variety: fast and weak to slow and strong, increasing in numbers as the game progresses and you get more upgrades

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press

[jimmy10hands]

Post-Mortem

Coming into playtesting I had a simple level design loop wherein the player had to traverse some obstacles and make their way to the objective as quickly as possible. There was a timer in the top left that would count up from the start of the level until they reached the timer, wherein it would freeze and that time was more formally displayed on the middle of the screen as the scene time slowed dramatically to give a slow-mo effect, before resetting the scene after a few seconds. This last part was done so that it would be easy to simply start up new levels at each objective, but for now it's just the one level.

Another feature was that if the player fell off, once they reached a point the camera would freeze in Y direction, giving the illusion the player had fallen off screen before respawning at the start point. During this time, the timer does not stop and continues to count up as a form of time penalty for falling.

Results:

Players were a fan of the concept, but would have really loved a leader board (as would I)

One felt the speed or jump mechanic didn't quite feel right, which I kind of understand. A wider but lower jump might feel more appropriate.

I talked to players about the level design, and even let them fiddle with it and try to explain how they'd like it, which was an interesting insight and gave me an idea for implementing user created levels.

A little confusion on where the objective was on first time playing, so implementing some sort of indicator for that would be a good idea (arrow, minimap, etc)

Overall, the players gave some valuable feedback on some pros and cons of the game. The consensus seems to be that the premise seems engaging to some in a competitive sense, GIVEN that the levels are well enough designed to make them somewhat challenging, as well as having multiple potential paths to the objective, as one linear path is always guaranteed to be the fastest, so choices help add to the element of replay-ability.

If I were to continue to iterate over this into the future, there are several changes I'd love to see.

those described above (Objective marker, Leaderboards, User level design feature)

A more unique aesthetic, as while the alien gets the point across, it doesn't feel unique or match the experience of the game very well.

In general, I'd say I'm pretty happy with how the idea turned out, and it achieves the initial goal I set out to achieve. From playtesting, several users seemed to be having fun with the idea and with these few improvements, possibly even adding the item system at some point, even if it's not in Gdevelop. What I also found was that this type of game isn't for everybody, as I found both in my own experience with my playtesting and through the readings, particularly chapter 4. Here it talks about "The Nature of Play" and that "play is not any one thing but rather a state of mind. " Fullerton goes on to explain the types of players where "each of whom comes to a game with different needs and agendas."(Fullerton, P103-104).

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press

[jimmy10hands]

Platformer Mid-cycle notes

After going through some of the readings and tinkering with Gdevelop for the past week or two (mostly the latter), I figured out a few important things.

One was that I came into this without much of a concern for the player experience goals, which was a mistake. Fullerton explains them as "...goals that the game designer sets for the type of experience that players will have during the game." (Fullerton, p12). I feel as though my only current goal is simply related to feeling fast and clean gameplay, but I'm content with keeping this as the player experience goal for my first gdevelop game. Similarly, in chapter 3 Fullerton brings up the topic of objectives, and this game's objectives definitely fall within category 3: Race but in the simplest form, which I'm okay with.

Second was that I'm not sure how I'd go about adding the random item rewards at the end of each level, so I've decided to leave that out for the time being and come back to it if I work on this project more seriously in the future.

Another, is that the leaderboard system seems to be only available to those that apply and I don't think I'm ready to put my first gdevelop game out there for that, so it seems like I'm stuck with just a local score display at the end of each level for the playtesting.

The last thing is that collecting enough assets that fit a single theme and don't feel out of place or have clunky white boxes (seriously idk why it's been giving transparent backgrounds this white fill I'm going insane) so I'm just going to leave the aesthetic of the game as the simple alien textures given in the tutorial.

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press

[jimmy10hands]

High Concept Statement & Elevator Pitch

n11031336 | James Starke

High concept statement:

The game is to be a third person 2d platformer (side perspective) called dash or crash*. As the name implies, the basic gameplay and player experience goal for the player is to dash as fast as they can from their start objective to the endpoint, while navigating platforms and trying to avoid falling into the abyss below. The premise, while nothing revolutionary is just something that comes from the mentality of trying to achieve the fastest completion time possible in games, often referred to as speedrunning. There isn't any specific target age for this game, as it would be appropriate for all ages, but to narrow it down would be to younger teen/young adults who have a competitive urge, can keep up with fast paced games and keypress timing, as well as want something quick to pick up and play so they can get back to work and/or studies.

As for motivation and reward, despite beating all your friends or just yourself, I've got an idea to implement receiving a random item at the end of each level, with the "rarity" dependant on how quickly you finished, to act as a reward system for player improvement, as well as a slight RNG element to add to replay-ability. Elevator Pitch:

The game title I decided to go with is "Dash & Crash", as it's a simple rhyme that really encompasses the essence of the game. A fast paced time trial platformer where the only objective is speed. Getting from one point to a marked objected as fast as possible whilst trying to figure out the fastest path, and avoiding falling into the abyss below.

The platformer in itself is relatively basic at its core, and therefore will be heavily dependent on the level design itself.

In chapter 1, Fullerton talks about taking inspiration from not only games, but "...the world around you." I wasn't quite sure where to turn for my inspiration, so I turned to something game related, but not a game itself.

The below image is of a Mario Kart 8 speedrun leader board of different Yogscast (a Youtube/Twitch media group) members, and is part of the inspiration for this game. As you can see, the drive to continue getting faster and faster scores and beat your friends or just yourself is the core mechanic of this game.

Additional Notes:

As for controls of the game, I'm thinking of simply sticking with the industry standard of WASD movement, and spacebar for a jump alternative. Seeing as there's a simplicity to the aspect of speed, I see no need to try and force some strange new control system to players, and leave it as intuitive to play as it can be. Changing this wouldn't be in line with my player experience goal and as such, the player centric approach.

Three unique selling points for this game currently are:

Fast paced: you're not committed for long periods necessarily, and simple enough (while still nuanced) for anyone to understand (easy to learn, difficult to master kind of deal)

The more you play, the more you'll learn the fastest paths and receive better items, getting better scores each time

Competitive/speedrunner element to achieve the fastest time amongst others

What about your platformer makes it unique from other platforms?

While it's difficult to make something completely unique, and I'm sure there are similar variations of this speed concept outside of speedrunning normal games, it's not a big field that I feel as though could be done well

Does you elevator pitch seem viable to make a prototype in GDevelop?

I do believe so. Gdevelop seems to have the appropriate tools to make this concept possible.

What can you feasibly do in the next week?

Achieve a simple first level with some start and end where the player is timed reaching the end (simple game loop).

What is the conflict of your game?

Obstacles, time

What is the player goal?

Finish the levels as fast as possible

How do you win or loss the game?

No technical win or loss, just trying to beat your own time I suppose

Sources:

Image: https://yogskarts.com/

Fullerton, T. (2018). Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press