nedanator11

[nedanator11]

Perfect Detox Postmortem

If I could change the prototype further, I would:

Add ranged attacks to enemies. As they stand, they are less of a challenge and more of a chore for the player to defeat.

Give the player health so they can die, and set their respawn point somewhere inconvenient or far away to incentivise survival.

Play with the jump height and player hitbox to create more satisfying platforming. The player tends to bump their head on the above platforms in the conveyor belt section.

#postmortem

[nedanator11]

Perfect Detox (A3)

Above are the One Page and One Sheet I created for A2. For A3, my group originally intended to develop a completely different prototype, and as my other two group members had little to no experience with art, I volunteered to take the lead on it.

Due to some unforeseen circumstances, we were required to completely pivot and instead develop Perfect Detox. All the game art I had created could not be used. Instead, we used game art downloaded for free from Craftpix.net. Some of the art I had created is below.

We had to make major changes to the prototype, and the styles I had incorporated didn't fit well.

Below is the play through of our final prototype for Perfect Detox.

(Link if video doesn't embed)

<https://www.youtube.com/watch?v=q-RdgNKDCBY>

(Link if video doesn't embed)

<https://www.youtube.com/watch?v=q-RdgNKDCBY>

#Youtube #development

[nedanator11]

Carfinite Postmortem

The final prototype for Carfinite was not as enjoyable to play as I had hoped. It was lacking a real challenge. Given more time, some additions I would make include:

More variation in the oncoming traffic speeds and spawn rates.

A more visually interesting background.

A more unified art style.

Occasional speeding traffic, indicated by a warning sign in its respective lane. These would travel much faster than the other cars and force the player out of certain lanes.

#postmortem

[nedanator11]

Carfinite Development

I began by setting up the player movement and boundaries. For the oncoming cars and trees, I used two timers that spawned new objects every 3.5 seconds, at which point their sprites (animations) would be randomised between two colors using RandomInRange(). The cars on the left side of the road would travel slower than the ones on the right to imply two lanes moving in opposite directions. The tree sprites were randomised in the same way the car colors were, as were their spawnpoints within a certain range. This prevented them from passing over the screen at a constant rate. I added a collision detection to the player and spawned the explosion object whenever it was triggered. This covered the entire view before changing the scene to the lose screen, on which the player is prompted to try again by pressing spacebar.

#development

[nedanator11]

Carfinite (Racing Game) Elevator Pitch

Carfinite is a top-down infinite scroller where players race and dodge obstacles to beat their high score. Using WASD, players control a car speeding down a highway, threading and weaving through oncoming traffic. The longer the player survives, the faster they travel. It is aimed at casual gamers looking to challenge themselves with progressive improvement.

#elevatorpitch #elevator pitch

[nedanator11]

ultrAViolet (Asteroids) Postmortem

I think I was a little too ambitious with the ultrAViolet elevator pitch and concept. Ultimately, I had to scrap the idea of a puzzle shooter and build something very similar to the classic asteroids game. Though the shooting mechanics I had implemented remained, they proved of little use to the player given the small scale. The prototype's biggest issue was that the asteroids spawned within the camera bounds. If the game were to be expanded upon, this should be remedied by having them spawn outside the player's field of view, then have a force applied that would send them in the right direction. I added a title screen and lose state to improve usability.

In games like asteroids, casual players can quickly lose interest if the core mechanics aren't enjoyable enough, as the only incentive to keep playing is beating your own high score. One way to fix this would be to improve the player experience by altering the controls and challenges, and another would be to expand the game by offering new challenges. I wanted to incorporate puzzle mechanics and level design to transform it into my own, but ultimately time didn't allow.

#postmortem

[nedanator11]

ultrAViolet Development

I have added a title screen and lose screen to the game. I have also added a health system, wherein the player begins with three hearts, losing one every time they collide with an asteroid. Of course, if that was all, the player would lose immediately upon collision, as the game would check for one every frame. To stop this, I implemented a short period in which the player is invulnerable after a collision, giving them time to reposition themselves. This was visually communicated by flashing the player sprite in and out - a broadly understood cue.

#development

[nedanator11]

Platformer Postmortem

The most difficult part of developing this prototype was trying to maintain perspective. As is discussed in Tracy Fullerton's book, it is easy for designers to neglect the player's point of view and become trapped in a feedback loop of their reactions to their own games. To avoid this, I tried intermittently acting as if I was playing the game for the first time, and occasionally stepped away for a day or two to try and empathise with new players.

My design process throughout was somewhat fragmented. I jumped into production without having a clear idea of what it was that I was creating. First it was intended to be a platformer akin to Mario, then it was a shooter, and the final product seems to be an odd combination of the two that doesn't do either one particularly well. The shooting feels strangely slow - something that faster bullets did not fix - and the platforming lacks polish. Though there are two main features that I feel work well (even if they are a bit janky): The conveyor belts, which make the level feel more animated, and the targets, which offer potential for interesting puzzles and navigation.

Aside from overall refinement, in hindsight I would consider changing the shooting mechanic to something more restricted. Perhaps if the player could throw objects at the targets and use melee as their primary mode of combat. If time allowed, I would also add a ranged attack to the slimes. As they stand now, they're not much of an obstacle.

For the next prototype, I intend to create a more cohesive plan before starting major production.

#postmortem

[nedanator11]

ultrAViolet Development

Movement

After building the base game by following the provided tutorials, I found that the controls didn't quite fit with what I envisioned the game to be.

I opted for WASD controls, which is admittedly a significant deviation from classic Asteroids. However I wanted the player to be able to shoot in one direction while moving in another.

These controls, however, allowed the player character to move off the screen. I considered implementing a wrap mechanic, where the player appears on the opposite side of the screen from which they disappeared, however this would conflict with the level designs I intend to create. So I opted to create bounds that the player couldn't cross. With GDevelop's physics engine, though, this quickly became more difficult than I thought.

The "Stop the object (remove all forces)" action didn't seem to work when the player's x and y positions were checked, or when the player collided with bounding box sprites. The reason for this was unknown, and I couldn't find much documentation explaining, but I suspect it may have something to do with the "Stop" action coming from the antiquated "Physics 1" when the rest of the physics was handled by "Physics 2".

Regardless, I developed a work around in which I manually set the object's linear velocity to 0 when it was situated outside of the bounds. Even still, this created a problem where the player would get stuck beyond the bounds if they collided with sufficient speed. So instead of setting the velocity to 0, I set it to 50. Although this created a kind of bouncing effect like those DVD icons, it was the best result I could manage.

Shooting

If the gameplay doesn't reward selective shooting, then there is no reason to ask the players to keep the left mouse button pressed - the bullets may as well be automatically shot. So I implemented a mechanic in which the player can focus their aim by holding the right mouse button, making the bullets completely accurate* while also slowing the player's movement. This allows the player to choose when they want to prioritise accuracy over speed, or vice versa.

*When the right mouse button isn't pressed, the bullets fire randomly within a 12 degree range of the intended target using the following action:

RandomInRange((spr_Player.Angle() - GlobalVariable(var_ShootAngle)), (spr_Player.Angle() + GlobalVariable(var_ShootAngle)))

The variable "ShootAngle" could then be changed depending on the right mouse input.

#development

[nedanator11]

Week 8

ultrAViolet Elevator Pitch:

"ultrAViolet" is based off of the classic Asteroids shooter. Because the basic concept of this type of game originated in arcades, there is often an emphasis on repetitive gameplay that challenges players to beat their high score. To adapt this to a more modern scenario, the fast-paced gameplay will focus on stages and diverse level design. Players will control a small spaceship using WASD and will interact with the world primarily through shooting, which will be controlled using the mouse cursor. To keep players visually engaged, the prototype will utilise a wide colour palette that contrasts the expected white on black that is common of Asteroid shooters.

#elevatorpitch #elevator pitch

[nedanator11]

Week 5

Platformer Elevator Pitch:

Combining the mechanics of 2D platformers and classic shoot-em-ups, this game will engross players in a wide and ever-moving world, with an emphasis on interactive level design. Your gun is more than just a weapon.

Platformer Development:

The first obstacle I added to the prototype was, of course, the slime. Initially it would be destroyed if the player jumped on top of it, however, with the addition of the gun, I felt that having two vastly different means of combat would not only betray genre conventions (i.e. the classic Mario mechanic with guns), but also make them less of an obstacle and subsequently less fun.

Speaking of Mario, there was one gameplay feature I wanted to implement, inspired by New Super Mario Bros Wii (I'm sure this has been done countless times before that game, but it's just where my mind went). The mechanic involves conveyor belt platforms that trolley objects which then fall to the ground (see image below).

(Side note: I just thought about it for a moment and the jump-through platform is truly an amazing invention).

So I retrieved a barrel sprite from the industrial pack and applied some forces to it. While they can't crush the player like in Mario, they are fun additions to the conveyor belts.

After trying and failing to implement a double jump, I decided to add targets that would reveal hidden platforms.

Now there were platforms that the player could reveal, but I also wanted platforms that the player could make disappear. With this, I could create a path the player must complete before advancing to another area.

#elevator pitch #elevatorpitch #development

[nedanator11]

Introduction

Hey everyone. My name is Ned, and this is my IGB220 Blog. I'm majoring in Game Design and currently in my second semester. While I love writing and storytelling, my main goal for this unit is to create prototypes that are basically fun to play. I've never used GDevelop before, but am confident that my familiarity with other engines will lessen the learning curve (also helps that there is no raw coding). I'm somewhat competent at 3D modelling (kind of), however the assessment items seem to all be in 2D, so I'll be relying heavily on free assets - at least for the first prototypes.