jamierobinson

[jamierobinson]

Assignment 3 Postmortem (Arctica)

If further development of Arctica was to be done, I believe the first and most urgent issue to be fixed is to implement GUI. A title screen would be good and maybe even a cutscene or bit of text showing the player the story of the game. Then once the player picks up an upgrade it will show the player through both text and images what each upgrade does.

Another would be to massively increase the amount of useless assets like rocks or trees. As right now the game is bare bones with just backgrounds, background tilesets and the tilesets used for platforms. Implementing more assets will create a more realistic world that will allow players to step into that "magic circle" stated in Week 3's lecture. They can also be used as landmarks for players to allow them to recognise unique structures/assets in rooms to further improve their exploration experience. This is important as Arctica's fun comes from Lazzaro's easy fun stated in Week 5's lecture. Additionally stated in week 5's lecture is immersion and Arctica capitalises on Adam's narrative and tactical categories of immersion.

Another addition that would lean more into the easy fun style of gameplay would be by increasing the time the player has away from the campfire and adding in safe zones that don't drop the players heat. This would allow for more time exploring and an overall more casual experience for the player.

Additionally, more branching routes the player could take will make the player feel like they're really exploring this world. It will also allow for a more authentic experience as it no longer becomes linear and instead every player has a slightly different playthrough of the game.

[jamierobinson]

Assignment 3 Playtesting (Arctica)

Playtesting for Arctica unlike previous prototypes in the course followed a strict structure of letting the player experience the game without outside interference. This allowed for an authentic feedback that will allow for an improved game.

Before playing play testers were asked to fill out a survey that categorised them based on what their experience is and what types of games they enjoy. This will be used later to prioritise feedback into important (people who enjoy platformers) to unimportant (people that like FPS and dislike platformers).

The structure was that players were told what the controls were and observed asked to think aloud as they play so we can get an understanding of how they were thinking whilst playing through certain areas.

After playing through the game the play tester was then given a questionnaire that quizzed the tester on everything about their experience with Arctica as to make sure we got the most feedback.

The main concerns was that players did not understand what upgrades did as we hadn't focused on any GUI and just made the game itself.

Additionally, the player did not understand the story of the character because they were just put straight into the game. This gave many play testers no direction or purpose resulting in no drive to play through the game.

Another relatively large issue was that due to the repetitiveness of the game and assets it became harder for players to distinguish between rooms resulting in players getting lost as the game loops back in on itself multiple times. It also does not help that the games intended purpose is to have a sprawling map yet due to the confines of the prototype it cannot fulfill that.

The play tester feedback was taken and sorted from most important (game breaking bugs/issues that resulted in players being unable to complete the game) to least important, (dislike of aesthetic or genre of game). The players genre preference was also taken into account when choosing which concerns were important or not.

It was made sure that no one showed any attachment to the game as to not persuade the play tester into being not as truthful as they should be. It was also made clear to every play tester to be brutally honest about their opinions of the game and not hold back as to get the best feedback.

[jamierobinson]

Assignment 3 Development Progress Assets (Arctica)

These are the tilesets I made to generate the world in Arctica. (everything is 8x8 so it looks a bit bad when not properly scaled up)

Additionally these are the other assets I made for the game Player:

Backgrounds:

Campfire/Checkpoint:

[jamierobinson]

Assignment 3 Development Progress (Arctica)

During my development of Arctica I mainly focused on the art and the level design whilst still assisting (and bug fixing) the programming.

My objective with the art was to create a story and character that the player could feel sympathy for. With this I ended up designing a cute little fox with the main features being their small stature and large eyes.

The story of this little fox is that they were separated from their family in a massive snow storm and needs to find them again. By doing so the fox (player) will need to explore a frozen world and collect movement upgrades until eventually they make their way back to their family. Similar to seeds mentioned in Week 2's lecture I want the player to feel alone and melancholic and want to help the protagonist. I do this through the palette being calm and use more blues or darker colours with the occasional point of interest being coloured differently (campfires which act as checkpoints and the player themselves and the thermometer in the top of the screen that tells them how much heat they have left). Due to the nature of the games aesthetic and story it is not going to be an extensively difficult game to beat so the challenges presented to the player won't be overly stressful, the challenge will come more from exploration through spatial awareness and a maze like layout of the world as covered in Week 7's lecture.

Creating the levels/world for Arctica involved knowing the limitations of the player and what each upgrade gave them. The base player can only jump one block. (the upgrades are to be collected in this order)

-Climbing allows scaling walls except ice -Dash allows horizontally moving 3 blocks (can make it over 2 block gaps without jumping) -Double Jump just allows another jump

With this information I designed each area around what upgrades the player had. The first area will include a lot of vertical walls and holes that the player falls down and once they find the climb upgrade they will be able to retrace their steps to the next region.

An ice cave that uses ice to stop the player from being able to climb in certain areas to limit the players use of the climb (player enters through blue arrow in and exits on blue arrow out). Preferably there would be more rooms between each region to let the player enjoy using the climb however this is a prototype designed to test out the features of the game and so cannot be too long.

After finding the dash in the ice caves and using it in conjunction with the climb to escape the player will hopefully remember a room between the two first areas where there is a dash exclusive obstacle (circled in red). This will lead the player up to the final upgrade, the double jump.

This area is quite self explanatory in the direction the player must go. This area will require both the climb and dash used in unison to progress through and at the very top left will be the double jump.

Currently I have not done any work towards an area that uses all three upgrades because I am stressed on time.

The map was made using Tiled a free tilemap and tileset editor. The tilesets were imported in and collisions were set up so when the map was exported into Gdevelop I was able to connect unique collisions for the top side and bottom of each tile. This means instead of just knowing if the player is touching a tile we can know exactly which side they are on and if it's ice or a oneway platform. Allowing for easy implementation of a climb upgrade that only activates on the sides of non-ice tiles or any further upgrades that might be added.

[jamierobinson]

Pursuit Post Mortem

If there was further development on Pursuit, I would definitely introduce more elements of danger such as obstacles that come from different directions as right now there is no point in moving up and down which is a real missed opportunity as it makes the player think in a whole other dimension in addition to the slow mechanic.

I would also slow down the game more, right now it goes from too slow to way too fast really quickly and kind of misses that sweet spot necessary for fiero. If I could tweak the values more I would give the player more time for time slow (as it allows for creative ways to evade obstacles) and I would figure out where players are most focused and engaged.

Additionally, the free flow movement felt either sluggish or too fast and I could never find a perfect middle ground that would allow the player to feel like they have complete control. Something better I believe (and many of my friends that playtested suggested this) would be movement that snaps between columns as it allows for instant gratification and the player cannot overshoot where they want to go as it simplifies it down to pressing the key once in order to evade something (this was done in the Muffet boss fight in undertale and worked quite well). This made for a more enjoyable experience when I implemented it. Also, I made it so the laser would only kill the player if they were in the column when it struck instead of the entire time (even if it was tweening away). As this caused confusion in players seeing as most other games with laser mechanics have them be single bursts of damage and not linger. Another feature to add to the laser would be to have set patterns for when there are two of them. this will result in them being not as random and allows the player to recognise the patterns and be able to act accordingly, this was mentioned in Week 2's lecture as it is good to have randomness but not too much as it creates a chaotic environment that the player cannot anticipate.

A highscore page was also added in after the player dies, this shows what score they got on that run and the highest score they've achieved since running the game.

[jamierobinson]

Pursuit Development Post

Before development it was important to figure out what the challenges for the player would be. I ended up choosing 2 obstacles for the player to evade. A projectile that will come at the player from the top of the screen, similar to the work done in the workshop, and a laser that will instantly cover an entire lane. These will give enough variety for the player to remain focused on the game, additionally increasing the speed of the projectiles and time for the lasers to come out will introduce stress, in addition with the intrinsic skill required to dodge the obstacles will result in a difficult experience for the player. This was all covered in Week 7's lecture.

Additionally, the time slow ability the player has will remove this timed element for a short while allowing for the cycle of fast and difficult and slow and easy during the moment to moment gameplay, hopefully captivating the player in the game and inciting fiero within them.

Now with the core moment to moment gameplay figured out, I started with the scaffold of the workshops content as it already had player movement and the projectiles for my idea. I then stripped back the assets and replaced them with simpler and easier to replicate ones. This was done as it is easier to produce a cleaner look with simpler graphics and it will result in the player being able to focus on what is important (the player themselves being a coloured square, the laser indicator being flashing red and the time bar turning red when the player is using it too much)

The next step was to make the next obstacle, lasers. This was a relatively simple feature to add as it was simply a long white rectangle that shrank in size from a tween. The warning was made a bright red that would blink rapidly in the column the laser would strike. The player was given 1 second to get out of the way which I though was a generous amount as the average human reaction speed was 300ms additionally the player would have access to time slowing meaning they would have plenty time to get out of the way.

Now it was time to add time slow. This was the most important as it was the main feature that made this game different to others. And so I wanted to make it as realistic as possible to further envelope the player in the world (The magic circle) as stated in the Week 3 lecture and in the textbook. This meant the projectiles had to move slower, the lasers had to fire slower and come out later and the spawn rates of both needed to adjust for when the player slowed time. This was partially made easier through Gdevelops built in time scale feature that slowed down everything in the scene however since timers were not a physical object in the scene they were not slowed down. This was an issue because timers were used for spawn rates of obstacles. Resulting in more obstacles spawning closer together when time was slowed. This was mitigated by changing each timer into a variable and a separate timer that would add to them every second and changing the check for this new timer to 5x what it would be normally if the player is slowing time.

Finally, I introduced a simple hidden scaling system that after certain milestones in score would increase the speed and tempo of the game, this allows for exact scaling for certain points, the speed of the bullets still slowly ramp up as the max speed is changed however it means I can keep players at certain difficulties for certain amounts of time allowing me to introduce them to new features or get the used to faster speeds. After 120 score or 2 minutes of gameplay I set everything to the max if anyone wished to keep going, however this prototype is not intended to be progressed past 120, it is essentially winning the game as there is not enough time to create more in depth scaling.

The final game should look something like the gif below (I altered the hiddenplayerscore variable to 60 to showcase the full game)

(The game does start to bug out when there are two lasers however) https://necromancer00.itch.io/pursuit this is the link to the game if you wish to play it :)

[jamierobinson]

Pursuit Elevator Pitch

In this fast paced "racing" style game dodge in coming balls and lasers whilst slowing down time to give yourself an edge when it's needed, but be careful, slowing down time for too long can be deadly! Survive for as long as you can as the game gets progressively more intense and try and achieve the highest score. This game is an undertale boss fight meets time control.

The player will use WASD to move and SPACE to slow down time

Unique Selling Points: -Time control -Variety of obstacles to dodge -Increasing difficulty by increasing speed and introducing new elements as game progresses

[jamierobinson]

Spacemercer Post Mortem

To continue development of Spacemercer it would probably be a priority to figure out the inventory/storage system and the buying and selling aspect of the game. During development I spent the majority of the time on trying to perfect the AI for the enemy as it was the first time i worked on "intelligent" enemies. However, I should have focused more on the other aspects of the game and tried to make the game fun and enjoyable. As the state it is in right now is not very rewarding to the player. The AI will swiftly dodge out the way of player bullets and the only time they die are to asteroids if they overcorrect when evading. This doesn't give the player a sense of accomplishment as it almost feels as if they have no impact. To fix this issue, I would either remove the ability to shoot in the first place for players so their only option is to evade. Or, change the controls of the player to mouse and keyboard to allow more precise shooting and dumb down the AI to make them more fair as stated in Week 6's lecture.

Currently Spacemercer is lacking depth. There aren't any objectives except survive. To expand the games complexity I believe adding in a way to beat the game would help along with potentially being able to beat levels. Instead of one level that gets increasingly harder, maybe have each level be a different difficulty. The level difficulty could increase or decrease depending on the wares the player is carrying (more valuable stuff means more money, but if you can reach the other port, more enemies want that loot). This will allow for a hierarchy of challenges (stated in Week 7's lecture), high level would be to beat the game by making a bunch of money (maybe player only has a limited number of days to make as much money as possible). The intermediate level challenges would be knowing which ports to buy from and sell to to get maximum profits. The low level challenges would be surviving journeys between ports and evading asteroids and enemy bullets.

[jamierobinson]

Spacemercer Development Post: Making (Simple) AI for the enemy!

In order to fully immerse the player in the world I needed to add enemies that will interact with their environment and the players inputs. These AI will hopefully create an immersive and always changing environment for the player to be constantly invested in.

The first feature implemented (aside from looking at the player and shooting) was allowing each enemy to avoid asteroids and player bullets. This was a very simple addition however, it caused a couple problems.

The first being that the enemy would speed up after each evasion because I was adding a force to it each time, eventually leading it to fly into an asteroid.

This was a somewhat easy fix as I just checked if the forces applied to the enemy exceeded a certain amount and halved it. I made sure the max speed wasn't very fast and I made sure they didn't dodge as far when it was a player bullet as to make it more fair for the player.

The second issue was that because the enemy could loop on the screen they would on occasion fly into something on the other side of the screen as they couldn't see what was there. This was a lot harder to fix.

The solution I came up with was giving each enemy two additional collision boxes.

The red is tied to the enemies X coordinate whilst the blue is tied to the Y coordinate and both are inversed so they are the opposite side of the screen to the enemy. This means when the enemy is on the edge of the screen they have a detection box on the other side of the screen to check if they will collide with something.

Now with the enemy's AI done I added in a simple scoring system that incremented every second. And a way to see how many enemies have been destroyed. Along with player health which should be set to 10 (the gifs above have 10000+ for debugging purposes only). Additionally, I implemented a rudimentary scaling system whereas every 2 seconds the enemy spawn rate would decrease by 0.1s.

As finishing touches I also added in a start and lose screen (player has 1 HP in gif to easily display both start and end screens).

The start screen was simply so players wouldn't be put into the game instantly and the lose screen displays the players score for that run.

[jamierobinson]

Spacemercer Elevator Pitch

Play as a merchant spaceship trying to traverse between planets in order to sell your wares. Protect you ship from the likes of bandits and pirates trying to steal your goods or evade environmental hazards that could destroy your ship entirely! This game is Asteroids meets Backpack Hero.

the player will use the mouse to move and shoot. They will also use the mouse to sell and buy wares and then store them in their ship. The player ship will act as their inventory and if their ship is damaged then their inventory is damaged.

Unique Selling Points: -Travel between different planets/solar systems in order to sell your goods for higher prices -Strategically store your wares on your ship, if your ship gets damaged where you stored your goods they might get lost. -Unique Enemy AI that will try and avoid player bullets and environmental factors.

[jamierobinson]

Postmortem of Platformer Game

When developing the game I was only able to finish one of the main features, allowing the player to use their body on death as a platform. Thankfully, this was able to be adapted into a playable prototype.

However, the feature itself did not turn out as planned. I was unable to fix the bug that occurs when the player pushes 2 blocks into a wall. On the contrary I was able to fix the bug where if the player stood on two or more boxes they would slide into each other. I can probably blame these issues on the physics engine still being in an experimental phase. If given access to a proper game engine I'm sure I would be able to implement a bug free version of this feature.

There were many other features created that I did not plan on adding such as smoothing of the camera and even having a delay between when the player dies and when they respawn. These features were received well in play testing however the speed at which the player moves was too fast for most players.

If I were to give advice to someone that wanted to remake this game. I would suggest using a physics engine that properly works and to scale the scope of the game according to time constraints given.

[jamierobinson]

Development of Platformer Game (Development Post Part 2)

In this post I will focus on how I use my knowledge of game design to develop this game. The first and most important feature to make was the ability to drop a block on the players death. This was very simple as it just involved spawning an object when the player touched spikes.

After that I implemented a simple checkpoint system by saving the coordinates of the last checkpoint object the player collided with.

Now when the player touches spikes they will spawn a block with the platform behaviour and then the player will be sent back to the last checkpoint. This works for allowing players to jump on the block however the block just floats there as platforms are not affected by gravity. This also doesn't allow the player to move the object around as they will just collide with it.

To fix both of these I created another block the same size with the PhysicsEngine2.0 behaviour and set the platform block's position to always be this new physics block's position. This was the block is affected by gravity and the player (which also has the PhysicsEngine2.0 behaviour) can move it around.

As seen in the gif above the features I stated have been implemented. The black part of the box is the physics block and the red is the platform. The platform is slightly skinnier than the physics because when pushed there is a couple pixels of overlap between the player and the physics block, and so because of this the player would collide with the platform inside the physics block and cause a stutter effect. This was fixed by simply decreasing the width of the platform block.

Another feature shown in the gif above is the smoothing of the camera. As a main feature of the game is the player dying repetitively, I wanted to avoid having the camera snap onto the checkpoint when the player dies. So to solve this issue I gave a 0.5 second delay from when the player dies and when they respawn and gave the camera smoothing. This made it so when the player dies the camera will slowly pan towards the checkpoint the player last touched and then the player will spawn in.

I also added a death counter so the player could keep track of how many times they died, so they can compare with their friends on who has the lowest score.

Right now the game is very simple in what can be done, so I decided to add in a feature very common with puzzle platformers.

By adding a button and door mechanic, it allows for much more complex puzzles to be made and so will hold the attention of the player.

This feature was quite easy to implemented. The door is just an object with the platform behaviour and the button is a trigger for the door to become nothing by decreasing the scale to 0 when it is actively being pressed by the player or a physics box.

I tried to make it obvious for the player what needs to be done by having spikes right next to the button and showing that the button opens the door but closes it when the player steps off it.

The spikes were originally over the button however I noticed if the player didn't touch the checkpoint to the right they would have to jump of the block and when I tried to do it I would hit the spikes a lot. So to avoid this I shifted the spikes slightly to the right so if the player tries to jump they won't hit the spikes.

[jamierobinson]

Design of Platformer Game (Development Post Part 1)

Given the scope of the game and the time constraint I decided to just focus on one of the many features for the overall project. This was the zombie mechanic where the player uses their dead body as a platform/pushable object.

Before starting development on the game itself I went through all the formal elements as stated in Chapter 2 of the Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition textbook (will be referred to as 'the textbook' this point onwards). As a way to properly design what needs to be created.

Now, obviously there will be a player and their objective is to reach the end of the level with the fewest number of deaths. The procedures allowed by play is the player being able to stand on their dead body after respawning. The rules implemented that bound the player are just like many other platformers, a finite number of jumps (1), collide with walls and floors, gravity constantly pulling the player' downwards and they can only run left and right at constant speeds. Resources the player has access to are themselves as when they die they create a block which can be used to help them complete their objective. This way of collecting resources can cause conflict as the player will have to give up their position and increase the number of deaths. Outcomes for this game is the satisfaction of being able to reach the end of a puzzling level and finishing it in the lowest amount of deaths. There is a constant battle with the player wanting to finish the game/levels in the smallest amount of deaths. However they must die to progress. Causing the player to constantly strive and find the situation which leads to them dying the least. The challenge of this game comes from the scaling of each level at a constant rate as to not cause the player to give up or feel like its too easy. For example, early on the only spikes available will be exactly where the player needs to put the blocks. This is an easy way for players to see what needs to be done. However, later on the amount of spikes in a level will no longer give the player easy hints and so they will have to think for themselves. The play generated from the given rules would be players using the resources given to complete levels, either by using the blocks as improvised platforms or to block bullets or to put on buttons in order to open doors. In the original idea for the game it was set in a scary crypt with enemies and the player (a ghost) would see this small child scared ad help them through the crypt until they escape. This would have players form a connection to the child as they would want to keep them safe and want to see them escape causing the player to be invested and continue playing.

Overall, with these elements in mind when developing this game it should; be a closed formal system that engages players with conflict by making them decide whether trading off a lower score for easier platforming and puzzle solving is worth it. This will result in an engaging and enjoyable game for the player.

[jamierobinson]

Platformer Elevator Pitch

You play as a ghost that wants to lead a lost child out of a crypt. Possess different monsters, ranging from skeletons to bats or even spiders to navigate treacherous rooms that contain spikes, pitfalls, and dart traps to make sure the lost child gets out safely.

Similar aesthetic to these images.

The player will be able to fly around anywhere on the screen. Using arrow keys or 'wasd' and be able to possess/unpossess any enemy they are hovering over by pressing shift.

Players will be able to possess various enemies around the crypt to unlock their special abilities: -Zombies can be used as platforms by jumping on spikes -Skeletons can walk through dart traps -Spiders can create swings for large gaps -Bats can hold platforms up -Slimes can slip into tight spaces

The player must be careful when unpossessing enemies as they will try to attack the lost child if they can see them.

Because the player is a ghost they can fly anywhere even the exit, however they can only win if the lost child gets there safely. This forces players to figure out unique solutions given the enemies they have available. Once there is a safe path to the exit then the player can possess the child and walk them to the exit.

[jamierobinson]

Introduction!

Hello! My name is Jamie and I have been absolutely infatuated with all aspects of game development from a young age. Ranging from level design and programming to even the artwork and sound design. I find it fascinating how all these elements can come together to make an enjoyable and interactive experience for the player.

If I had to choose the one aspect of game development I am most interested in I would have to say programming. I love being able to write a script and watch the character I made move around and interact with their environment.

My hopes for this unit are to be able to learn what makes a game enjoyable for a player and be able to recreate that in my games. Also being able to know the process of game development and which way is the most efficient will be very useful later on in this bachelor and in my future career.