Team Members: Alex Yuan, Addison Goolsbee, Matthew Qiu, Rylan Polster
Download Mac and Linux Binaries with Source Code
The instructions to compile/run the game and the GUI are located in README.txt within the Engine/ folder of the this download.
If we had an additional 8 weeks to work on this project, we would allocate this extra time to push for a few major improvements. The first major improvement we would make is to add "layers" to our tile editor in our game engine UI. We implemented parallax inside the engine itself to have cool backgrounds for levels, but we realized that this parallax clashed with our grid-based tile system that we used to represent levels and serialize/deserialize them. Furthermore, since the game engine UI level editor uses a grid system, we would have to represent background parallax another way. The improvement would be to implement layer tabs in the level editor with a boolean flag that allows you to designate layers as grid or non-grid layers. The non-grid layers could be used to place background objects for parallax effects in your level while the grid layers would be used to place the normal game tiles. This was an oversight in the original design of our GUI that we didn't consider the complexity of until the end of the project.
The second major improvement that we would undertake is complex tile movement patterns. Taking inspiration from our 2D platformer games like Mario, many of the enemies there have complex movement patterns (they move in rings, they automatically detect when they can jump upwards to another tile, or they follow the player). While we have a very in-depth gravity manipulation system, we do not have the capacities currently to support the creation of these complex movement patterns of enemy game objects within our GUI interface. We would make the improvement by adding a way for users to easily perform custom movement scripting and custom AI scripting at the GUI-level to enable this functionality. This would definitely require more heavy-duty work on the interface between our D engine code and our Python GUI code.
In terms of tooling, there is also the consideration that if we had more time, we would switch away from Python for the GUI development. While it allows for quick iteration, as the complexity of the project has grown, so has the difficulty of the lack of strict typing. Upon reflection, the time saved by using Python for GUI development via its fast iteration was probably balanced out by the numerous bugs that come as baggage with using a dynamically typed language like Python. Ultimately, the code would be more easily understandable to an outside observer if it was a strongly typed language rather than a dynamically typed language, and it would likely enable better scalability with respect to compounding complexity as our engine expanded with the new features we mentioned before.