1 of 13

CSP: The making of

A Shmupformer

Designing, Failing, and Leveling Up

Yingjie Yu / Zhiwei Huang / Zining Tang

2 of 13

Introduction

Initial Idea

-What if: shmups fused with platformers, while keeping each gameplay loop completely harmonious?

-Press jump, and then jump again to transform into flying mode

-flying mode shoots automatically at a locked location

-Flying mode consumes a stamina bar that will regenerate when outside or refill on the ground

Story

-Shooting bullets vs. emotional screaming

-narrative about suppressed emotion

Commitment & Retro Design Philosophy

-Modern games emphasize accessibility and ease of play

-Since we are fusing two very retro-inspired genres, our gameplay would be more challenging with large commitments in gameplay (e.g. cannot change direction when locked)

-Pure bullet hell: players will navigate bullets instead of removing or avoiding them with invincibility frame slike modern games

3 of 13

Pre-Production Period

From idea to sketch, from sketch to product.

4 of 13

Inherited Experience (from previous projects)

Pre-Production

-Shared documents to record ideas

-Mind maps to test out mechanical possibilities

-Consistent meetings with all members to communicate

Visuals

-DO NOT IMPLEMENT VISUALS UNLESS THE CODE IS COMPLETELY STABLE

-If art is made for a object or element that is scrapped during testing, it is wasted labor

-Utilize simple placeholder sprites for testing

-Always prioritize coding over visuals for a prototype

Design

-Start with ONE CORE MECHANIC

-having multiple systems (e.g. a visual novel that is also a maze traversal game) will double or even quadruple the workload

-Ideas are cool to motivate devs, but production has to be grounded in realist expectations

5 of 13

Why Gamemaker?

GameMaker Language (GML) is relatively beginner-friendly
Engine specifically made for 2D pixel art games
Consistent 60 FPS on low-end machines
Supports exporting to all major platforms (Steam, Switch, MacOS, html5, etc.)
built-in sprite editor, animation tools and tileset managers

Dev Tools and Why we use them

GPT Support?

cannot write complex code in GML without bugs
can speed up our process phenomenally based on already-written code

The correct way:

We plan the specific structure of the code
GPT fills it out based on our instructions

6 of 13

Coding Logic (that we learned)

Persistent objects

-Objects to persistent between rooms

-Use for ever-present objects in Initialization

(e.g. HUD/Health Bar)

Scripts

-Compartmentalized code/functions, highly customizable

-Easy integration into multiple different objects

(e.g. ScreenPause on hit and Pause Game)

Parenting

-Identify and Categorize objects

-Template or opportunity to inherit code

(e.g. Flying monster and crawling monster are both made from enemyParent)

4. Draw_text debugging

-drawing out text during gameplay

-allows real-time tracking of variables

-able to identify bugs in logic

5. Enum and Modes

-define & switch between modes

-encompasses most of enemy & player behavior logic

6. Variable editing

-Sometimes simple editing variables is most effective

-Saves time rather than writing complex algorithms

(e.g. giving the movement a 0.175 rather than writing frame-sync code for movement )

Scripts

-Create snippets of code than are contained inside a function in a script

-by inserting the function in any object, the object effectively gains the function’s code/function

-allows multiple customizable uses of certain functions (e.g. screenPause both creates impacts upon being hit and also pausing the game)

-Sometimes for a single function to work, it has ot be divided into create, step and cleanup blocks that all need to be inserted into the same objects (corresponding to the stages Gamemaker operates per frame)

Simply Numbers

-Sometimes tweaking numbers of a variable can work wonders instead of writing complex code structures

-By tweaking numbers to bullet spawn rate, travel speed etc of an enemy can make it look smoother rather than writing a complex algorithm to achieve the same thing

-Make as many customizable variables as possible to ensure full customizable control over everything in the game

Objects can persist/function through different rooms

-If we put multiple objects (e.g. UI) in an “Initialization” room that runs before everything else, we don’t need to reactivate them again through every room (unless there is a need to)

7 of 13

Prototyping & Iteration

Over many different versions of the game, various mechanics evolved over time.

8 of 13

Shooting

Original:

-Only locked to left or right in flying mode

-Restrictive since both dodging and attacking occurs on the same axis

Changes:

-Added a reticle to show where you are aiming, shrunk it down to balance visual priority

-Originally can only hold to enter flying mode, but added tapping to “float” because many players instinctively tries that

Final:

-360 degree free aim based on player input, able to lock direction for greater precision if needed

-Skill needed in controlling the player (lore accurate)

9 of 13

2. Overload

Original:

-Fills when player is in flying mode, discourages staying in it for too long as getting stamina regen in human mode is a core mechanic (you die when the bar is filled up)

-At one point becomes an MP bar to execute powered up attacks

-Scales with attack width & DPS to have greater risk & reward

Changes:

-Needlessly complicated and interferes with gameplay consistency

-shooting too much is impossible because the player will always be dodging

Final:

-No more death upon reaching overload limit

-Expanded more on attack scaling for more risk & reward

-Encourages finding boss openings and rewards players learning attack patterns

10 of 13

3. Stamina Bar

Original:

-Linked with flight mode

-Supposed to reward players strategically recharging or attacking

Changes:

-Greatly reduced at the start of the game

-Too much stamina and flying removes the joy of exploration

-Have very limited stamina teaches players to manage resources properly in tutorial

Final:

-Remains the consistent core mechanic with minimal changes aside from execution

11 of 13

Removed Mechanics

“Mario Stomping” on Enemies

-In a game where dodging bullets is a

priority, this becomes a liability

-Can potentially get players to be killed with much frustration

“Kamen Rider” Dropkick

-Same as the first, only that players have less control during the process

Powered-up shotgun blast consuming Overload

-Too complicated & does not serve a unique function

(no need to shoot through walls)

-Replaced by the new overload system on normal attacks

12 of 13

Player Feedback

What we changed

Smaller aiming reticle to not take up too much visual significance (compared to the player who has to dodge)
Added flashing hitbox on player to indicate importance & clarity of location
Significantly simplified tutorial using direct language instead of letting them indirectly figure out the controls from experimentation
No cooldown between mode transitions - natural player instinct was to continuously tap the jump button instead holding it down, so we made it a mechanic

What we insisted

Retaining the fly after jump mechanism instead of splitting it - because it was satisfying to control and a completely new way to play
Retaining manual aiming of the shoot direction - because mastery is a part of difficulty
No invincibility frames to avoid dodging - ensures player mastery over positioning, which is also integral to landing attacks

Player instinct is to fear and reject new mechanics, even if they are fun to play after becoming more familiar with it

13 of 13

The end! Enjoy our game! :)