#bopland

Now that we’re concluding development of our first 2-week cycle, I wanted to reflect on my first game prototype. The full play-through of the prototype is uploaded here:

Powerups

I didn’t get too much testing done unfortunately. However, I received a very important bit of feedback, which I even personally recognised after completing the prototype and playing it through myself. The rocket boots powerup feels good, but doesn’t feel very impactful. This is simply a limitation of the prototype. I didn’t actually create any terrain or other objectives that require the rocket boots, except for obtaining the missing part which essentially ends the game. 

Hitboxes

Hitboxes were a bit problematic in some cases. The default player hitbox was larger than the actual animation, which made dying to spikes feel awful. The player would visibly be at a safe distance from the spikes, yet the large hitbox would cause them to collide with the spike and respawn. Similarly, it felt clunky when the player would run up against a wall. This was very noticeable at the cave entrance, which has multiple steps which the player would keep running into. The large hitboxes didn’t create any massively frustrating gameplay, but fixing them definitely helped make collision feel smoother. The gif below demonstrates this. Look at how much excess space there is between the player and the wall originally!  

Space Gun

I was messing around with some sort of weapon that shoots projectiles. The idea was to have a weapon powerup that would be used to get through parts of the map packed with flying enemies. Obviously implementing all of this was out of scope for this prototype, but I still decided to mess around with some settings for fun. The end result was NOT functional. It would shoot in one direction only. Of course I forgot to remove this mechanic from my prototype before it was tested, leaving my play testers pretty confused...Overall, with a few little tweaks, the shooting mechanic could be pretty satisfying. It would likely be the next powerup I’d implement in further development of this game. 

Final Thoughts

This prototype ticks all the boxes I set for prototype 1, however, I definitely wish I made the rocket boots feel more impactful since powerups and the feeling of progression is one of the main selling points of the game. In terms of my development approach, I think I was far too concerned with having a fun premise and engaging overall story. Upon reviewing some other student’s work, I notice they put more thought into platformer mechanics. My platforms weren’t particularly challenging or interesting. I did try to add some variety with moving platforms, but they were more of an afterthought with crafting/resource collection/exploring taking precedence.

An important aspect of Bopland is progression - earn bops to spend bops to upgrade or unlock areas. This concept is introduced in the starting zone through rebuilding the bridge and accessing the rest of the level.

A couple of things happen here:

Player has to collide with the sign, use the interact key, and have a scene variable of 1 for “bops”

Broken bridge sprite is deleted

Fixed bridge object is created

Deduct 1 from scene variable “bops”

In GDevelop programming blocks, we use conditions to check the state of the variable.

The crafting bench logic is identical to this, with one addition. Scene variable “rocketboots” is set to 0 by default. When the player buys the rocket boots, the variable is set to 1, and essentially “unlocks” the rocket boots. 

Using the rocket boots doesn’t require a collision check. All we’re checking is whether the player is holding down X, and the state of the variable.  I messed around with some of the player object behaviours, namely gravity and jump sustain time, to see what feels the best to use. So if the condition for rocket boots is true, the player object behaviours are changed temporarily and smoke particle effects are created following the jump path. This makes for a pretty satisfying power up.

Beginning the prototype was difficult. This was to be my first game prototype and I felt absolutely overwhelmed. With this prototype, I know that it’s impossible to flesh out the entire game. I don’t have the time to create multiple missing spaceship parts, multiple powerups, while balancing multiple terrain and enemy types. I only have to capture the essence of the game: 

collect resources → craft powerups → explore new areas of the map. 

My goals with this prototype were:

Create one missing spaceship piece (initially inaccessible)

Create one powerup which grants access to the missing spaceship part

Introduce the resource and crafting options

Build a small level (cave system) with enemies (focus only on ground enemies, no projectiles or flying enemies yet

Art Assets: a Mental Block

It was difficult to start any part of development with free to use art assets - they just didn’t feel appropriate for the kind of environment I was trying to build. I’m not an animation student, I don’t have animation experience, nor the time to learn to make my own assets. I went with a super basic but stylistic approach. I found a space themed colour palette on coolors.co and created a 25px by 25px object for each colour. I set the grid to be 25px by 25px too, so I could cleanly design the level and easily modify it when necessary.

I did also modify and use some assets for the more difficult types of objects like enemies and the bops resource. I didn’t want those things to just be coloured squares. The other assets are from the tutorial resources and here.

Building a Tutorial: the Players Introduction to the Game

I wanted to introduce the story and the world to the player in an organic way. In chapter 4 of Fullerton’s Game Design Workshop, the traditional drama element of premise is described as “establishing the action of the game within a setting or metaphor”. This game requires the player to collect bops (dropped by enemies) in order to progress. If I were to introduce the player to a group of enemies immediately, they might understand that they have to defeat the enemy, that the enemy drops some resource, but what is the importance of this resource? Why are they even defeating enemies in the first place?

Since the level is non-linear and encourages (even requires) revisiting zones, I had to create a somewhat restricted zone to introduce the premise, before letting the player engage in the actual game. 

The main things the player needs to know, in order, are:

Spaceship crashed and is missing parts

Spaceship must be repaired

Bops are a resource. Defeat enemies to obtain bops.

Bops are necessary to progress.

With this design, the player spawns in a locked-in area, next to the crashed ship. If they go right, they run into a broken bridge which requires 1 bop to repair. This introduces the concept of bops as a currency - a requirement to progress. The other way takes the player to an out-of-reach, missing ship part (temporarily represented by a key sprite). When accessing this part of the area, the player collides with an invisible object, which triggers the spawn condition for the first enemy. When the player realises they can’t reach the ship part and start heading back, they encounter the enemy which drops the first bop upon defeat, enough to repair the broken bridge. The premise has been set and the player has a clear objective, without being told explicitly.

Transforming the Environment: Collision and Timers

Along with transforming the player, i’m interested in transforming the environment. I want to trigger events when the player reaches a certain point. The first instance of this is in the tutorial. When the player goes to look at the missing ship part, an enemy sneaks up behind them. 

The invisible collision checking sprite is represented here by the blue rectangle. GDevelop uses an “event system” as opposed to programming in the traditional sense. 

So “programming” this check was simply hiding the rectangle at start, checking for player collision, then creating an enemy at the spawn location. If the rectangle isn’t deleted upon collision, then the enemies continuously spawn as long as the player is touching the rectangle. This can lead to some pretty interesting interactions. 

Another interaction that I didn’t consider until I actually implemented it: after defeating an enemy, a bop is spawned. When a bop is spawned, the player has to technically collide with it, to increase the bop count as seen in the UI, and also to delete the bop visually (visual confirmation that the player has collected the bop). However, if an object is set to spawn at the enemy location, then it’s expected that on player collision with the enemy, the object will spawn. The problem is that as soon as the player hits the enemy, the bop spawns, then the player collides with the bop immediately, prompting it to delete. This creates a situation where it looks like the enemy didn’t spawn a bop at all, but actually, the events are just happening very quickly.

This first enemy was programmed to create a bop on collision. The second enemy was programmed to also create a bop on collision, but also unpause a timer. The event for the player to pickup the bop on collision now includes an extra condition which checks for time - if 0.5 seconds have passed, then the bop can be picked up.

This essentially makes the bop invulnerable for 0.5 seconds, during which time the player will technically collide with it, but it won’t delete. This isn’t exactly a functional change, but it definitely feels better for the player to see the bop before they pick it up.

References

This is the final elevator pitch for my first prototype.

Game Title

Bopland

Pitch

You wake up on a foreign planet in the aftermath of a spaceship crash – it’s your spaceship. What happened? Repair your ship so you can return home. Traverse through the world filled with dangerous enemies and terrain in search of the parts you need to rebuild. You discover that the world is filled with bops – a rare resource used to craft items to help you navigate to new areas. Along the way, you learn that you’re not the first one to crash here.

Control Diagram

Left + right arrow keys to move left and right.

Space to jump.

C to interact with object.

X to use Rocket Boots *MUST BE UNLOCKED*

Selling Points

The player has to manage their resources. Deciding which items to upgrade first directly impacts which parts of the world (terrain) the player can access.

Different terrain brings challenges, including different enemies and powerup requirements. E.g. player requires rocket boots to access cliff side.

Our first workshop had us work on an elevator pitch and begin work on our first prototype. I very quickly hit a creativity roadblock and struggled to come up with a satisfying concept. I’ve never made a game before, nor have I used GDevelop. I have no idea what the software is capable of, let alone what I’M capable of. Ideas were feeling very dry, and I couldn’t decide on a solid elevator pitch.

I decided to follow along with the GDevelop tutorial first, to get a feel for the software and see what kind of game I could reasonably create. This wasn’t as inspiring as I anticipated, so I started from the very beginning and followed some of the creative processes outlined in Chapter 6: Conceptualization from Game Design Workshop by Tracey Fullerton.

I began with a word document and wrote down my ideas - a conscious stream of thoughts. I ended with a document full of notes, but nothing was really conceptualised yet. I tried doing a mindmap, thinking that having some visual representation of the connections I make could be helpful. 

I kept returning to the idea of transformation. Binding of Isaac: Rebirth (one of my favourite games) incorporates this very well. The game has an absurd amount of items (400+) but if you collect 3 out of 6 “Guppy” items (Guppy is a cat), then the player transforms into Guppy and is given additional powers such as flight and increased damage.

(Images taken from the Binding of Isaac: Rebirth wiki)

From this point, I knew that I wanted to incorporate player transformation, likely through the process of obtaining specific items. I started to build upon this idea - perhaps instead of the player directly collecting the items, the player has to collect resources which can be used to craft items. This would be the moment-to-moment gameplay which became the seed of my idea. What’s left was deciding on a premise, a story which the player can engage with. 

References