原行・GENKOU

In Chinese, these two characters mean “origin” and “travel”. In Japanese, it can be read as “genkou”, not unlike the Japanese term for manuscript paper.

Though intentionally left vague, it is meant to embody a sense of undertaking a journey towards the beginning. The violin of the leifmotif, Journey, pushing the song ever forward; the full stop soaring towards the direction from which one begins writing. Surely, the circle of a true ending would break out of the grid, break free of order and structure.

The original idea was as follows:

  • Rhythm-based bullet hell
  • Bullets appear on screen to the beat of the accompanying music
  • Dodge bullets to survive as long as possible
  • (Optional) Make music loop with remixes and increased tempo
  • Otherwise, just loop without progression, or just end it after the first loop
  • Inspired by Just Shapes & Beats, Touhou Project, OSU, Rhythm Heaven, O2Jam, Audition, etc
Just Beats & Shapes, the main visual inspiration. It uses geometric shapes, which are certainly easier to work with than having to animate with sprite sheets.

This was a fairly doable project, where it required quite standard systems: generation, movement, collision, reset and end processes. There were also fairly few necessary elements: the player, the damages and the stage.

I also just wanted to try using my own musical compositions in a game, so I did. MIDIs proved to be a very extensive subject, though, so I opted to convert to WAV and use it as an import than a program-generated sound sequence.

What I did not realise was that I have 1) no prior experience with programming, 2) an affinity for making extremely solid base systems, and 3) an affinity for catering to game quality of life systems. As a result,

Part of said unbreakable foundation includes using various things such as classes, booleans and variables to ensure statements do not encounter critical issues. Debugging was also done extensively, where I tested for every possibility possible that I could think of to ensure there were no loopholes in the code.
  • I spent an excessive amount of time on creating an unbreakable foundation with no critical bugs,
  • succeeded in making said unbreakable foundation, but
An example of millis() usage. Here, millis() is used for timing: for 3000 milliseconds after collision, the player will flicker. In the second case, millis() is used much more dubiously: +83500/soundrate refers to the exact calculated timing of how long should elapse, modified to match a new soundrate.
  • lacked the time to focus on creating the rhythm system,
  • lacked a good idea of how to create said rhythm system,
    • this would later prove to be a major problem, where I discovered that it was fundamentally problematic to use millis() in a system where FPS is unstable
Generation of damage zones, which are all just randomly generated blocks. I had to divide it up into multiple zones too, as it would drop too many frames if too much data was being processed at once. Many issues are evident, such as possibilities of RNG creating poor paths, and using guess and check to figure out how many damage zones to have.
  • lacked engaging gameplay,
    • as damage received is based on time spent in damage zones, it’s very easy to cheese the system by speeding through it fast enough that no damage is received
    • no attempt was made to tailor difficulty levels through formulating paths for players to navigate, as opposed to just random generation
    • this was partially caused by another issue, where input caused far too rapid movement to allow for careful maneuvering
The code used to reset the game, bringing you back to the title screen after the ending cutscene has played (boolean fadedone). Two different ending cutscenes are possible, depending on how far you’ve reached (determined by how much millis() has elapsed).
  • included many quality of life systems
    • such as a loop back to the title screen, removing the need to reset the game by closing and reopening it, or
    • visual feedback for collision occurrence and damage reception, or
    • starting and ending cutscenes
Sprite sheet. For the falling animation, I wasn’t sure how to derive the necessary components from the first array, so I took a simpler route by creating 2 separate sprite arrays.

If we assume quality playability, key issues which would have to be resolved are as follows:

    • Deciding on a direction for engaging gameplay
      • Maze navigating, where the damage zones are instead walls which cannot be bypassed. The player would then have to try to navigate through it, where the death condition is falling off the left side of the screen (think Icy Tower)
      • Rhythm dodging, a la the original idea
    • Fixing the excessively fast movement to allow for proper navigation
      • Kee Yong mentioned inserting a delay on frame checking, such that it does not check for keyPressed on every single frame (which is the reason behind the rapid movement)
    • Editing the damage dealt formula to discourage touching damage zones at all
        • Invincibility frames proved to be beyond my understanding, but I will probably have to eventually make an effort to understand it

      Introduce initial damage, such that at the first moment of impact a certain percentage of damage is dealt, THEN for every subsequent moment spent in the zone, health values are drained

Fixing variables with millis() dependency which are currently using precisely calculated values than variables

    • Using the MIDI files directly and tying timing to that within Processing(I don’t believe this is a good idea, but entirely possible) Cutting up song into portions and tying sequences to the start of each segment of the song

Possible expansions would include the following:

  • An actual ending
    • Currently, set such that death is inevitable. Just a placeholder system, where I do not believe that should be the case, there should be a proper resolution
    • For now, 原 has no function attached (pressing will cause no effect but denial) but perhaps something like a second playthrough will allow it to be selected for a bonus stage?
  • Expanded gameplay
    • Different types of damage dealers. Not just out of bounds zones, but also moving squares, lasers, etc
  • Extended gameplay
    • Different levels and songs
    • Song looped with increasing difficulty (increased tempo, increased damage zones)

Certainly, though, I’ve learnt that I do have glaringly obvious strengths and weaknesses. That I have good awareness of where and why problems could possibly occur (though whether or not I can deduce the solution is another matter), that I have sufficient sensibilities to include easily-overlooked elements which greatly improve gameplay experience, but that I lack awareness of how to create engaging and effective gameplay. That I am good at recognising what is “additional” and knowing what kind of temporary concessions to put to make it seem complete even when incomplete, but that I am lacking in allowing it to remain incomplete, such that it’s difficult to do anything too extensive.

There’s also the fact that programming goes far beyond just games played with computer inputs, which I felt I didn’t consciously realise, like Brendan’s webcam filter program, or Joey’s music visualiser. I’m not sure if I will venture into such areas, since I feel like I haven’t adequately explored game programming (e.g. meta game, animation for visuals, interaction with various kinds of unique objects). It was a good realisation, nevertheless.

Published by

EC Chee

a local peanut (◡‿◡ )

Leave a Reply