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
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.
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,
- I spent an excessive amount of time on creating an unbreakable foundation with no critical bugs,
- succeeded in making said unbreakable foundation, but
- 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
- 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
- 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
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
-
- Deciding on a direction for engaging gameplay
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.