Hello! Our game engine is focused on rhythm games, a genre of game that focuses heavily on music and performing actions accurate to the rhythm of provided music.
Our GUI is constructed in Typescript using React.js and electron.
Because we have a music-centered idea, our engine allows for MIDI input, through use of the PortMidi library (needs to be installed separately).
Please do note that one of our dependencies, DerelictPortMidi, is currently incompatible with posix-based systems, although it does compile on Mac and Windows. We have made a pull request for the package to fix this issue, but this is unlikely to be resolved anytime soon due to the last commit being six years ago.
Edit (12/20/24): after 40 minutes of playing, finally an all perfect on the base map!
Left to right: Menu screen, Game screen, Beatmap editor. You can record maps in the beatmap editor and play them back in the game.
Here is a link to our documentation, which is generated using Docxygen.
Engine architecture diagram, showing how the different systems interact.
./app from your terminal in the directory the executable is contained in.
One thing that was turned out to be troubling towards the end of the project was building into an executable. Our build process is still relatively complicated, requiring multiple executables to be built independently of one another. This is in part due to our file organization, which places temporary (application-generated) files in the same directory as the source code. If we thought about the build process beforehand, we could have avoided this error.
Another point that we could still improve is that the GUI is still quite lacking in terms of feature parity compared to what is enabled by the core engine. This is because making each part of the engine usable from the GUI often required custom GUI components and recreating JSON shapes in both the frontend and backend. Before proceeding with this, it might be worth looking into some way to use the same component "templates" which are shared between the editor and engine.
Some example of missing feature parity is the lack of granular control over the JSON objects in the editor. Ideally, the editor would be a safe (non-breaking) way to interface with the JSON configurations, while still allowing any legal configuration that could be produced in a text editor.
Given more time, we think we could have done more with the MIDI capabilities of the project. MIDI input also allows for velocity data, how hard the note was pressed, and incorporating this data into a game would have been interesting and worthwhile. However, it is worth noting that this may be incompatible with keyboard-based input systems.
Finally, one thing that we learned was that we had to continuously change our code because we built while testing with a single game. We went off the assumption that premature abstractions are bad, but this only turned out to be partially true because of the abstract nature of a game engine as a tool (you don't know what you will encounter in a game), and the fact that we wanted our game engine to be usable for all kinds of 2D games. Hence, starting with more generalizable implementations of systems like input would have facilitated our development process (we ended up with a deprecated input component by the end).
This documentation website could also be polished up a bit more :)