This page aims to reflect the progress after having finished the bachelor's research project.

The original game “Surviving Sarntal” was created within a few days at the “Ferienakademie 2023”. In this project, we refactor the original game significantly. Therefore, our version of Surviving Sarntal and the original version differ in various ways.

The original game is based on the Entity-Component-System (ECS) using Flecs [flecs_library]. As a team, we decided to alter the project's fundamental architecture from relying on the ECS to an object-oriented programming (OOP) approach. Given our familiarity with OOP, we concluded that transitioning from ECS to OOP would allow us to create a codebase that could be more easily comprehended, expanded, and maintained by our team.

During the development process of the new version of the game, we decided that a complete reworking of the game's graphics was necessary. New and creative graphical elements were created for all aspects of the game, including the entities, terrain, and background, and were integrated into the rendering phase of the game.

Old game:

New game: {width=2560 height=1440}

As a new feature, we include a game menu. A start menu is shown once the game has been initiated, allowing the user to access instructions, modify settings, or begin the gameplay. An end screen appears after the hiker has died, which enables them to start another round of gameplay. We also add a pause screen, giving the user options to go back to the main menu or continue the game.

As part of the software engineering aspect of the project, we designed a modular game architecture that provides several key benefits:

• Ease of Maintenance: Since components such as rendering, physics, and spawning are isolated from each other, it is easier to modify, debug, or upgrade parts of the game without introducing side effects.
• Maintainability: New features or game elements (e.g., new items, enemies, or gameplay mechanics) can be added by extending existing systems without requiring significant changes to the core architecture.
• Testing and Debugging: We added multiple features for developers, such as a debug view (Figure 3) and a developer mode of the game that allows the running of predefined test cases.
• New Terrain: We extended our modular design to the terrain by creating a completely new class structure that allows for different terrains with various features to be added.

This modular structure enables the development team to build complex systems in a more controlled and efficient manner, leading to a highly extensible and maintainable game.

The original Surviving Sarntal was developed during the Ferienakademie 2023 as a proof of concept under heavy time constraints, hence it suffered from issues with code maintainability, extensibility, and readability. Therefore, we adapted the game from the flecs ECS framework to OOP, which required significant refactoring, including redesigning the game loop. Nonetheless, the new architecture, while less performant, is now far more modular and maintainable, easing future development.

Designing our own physics engine was another pivotal aspect of the rework. The initial implementation handled simple collisions with basic circular objects and a piecewise linear terrain. Our custom physics engine supports arbitrary convex polygons, which allowed us to introduce richer game mechanics and interactions. Though this increased the complexity of collision detection algorithms, our performance benchmarks show the engine is capable of handling a sufficiently large number of entities without significant performance degradation. However, future versions may require optimization for handling larger, more dynamic environments.

In addition to technical improvements, we reworked the terrain system by incorporating two-dimensional splines, offering a more challenging and visually engaging landscape. This change, coupled with the introduction of new mechanics like terrain fall-off and item interaction, has drastically enhanced the gameplay experience. The new audio and graphics have further transformed the original idea for the game into a well-rounded game.

In conclusion, the rework of Surviving Sarntal resulted in a more modular, maintainable, and engaging game. We applied core software engineering principles and best practices throughout the development process, ensuring high code quality while vastly improving user experience.

While our implementation represents a significant step forward, the project offers ample opportunity for future expansion.

Therefore, we want to mention some concrete examples and ideas that can be used as starting point for the further development. New items can be added such as a pickaxe or a gun that can shatter rocks. Competitiveness between players could be introduced with a leaderboard. Different biomes with different visuals and terrain generation can be implemented.
Another option is to offer difficulty settings to the user and implementing a coin shop for buying upgrades. Moreover, we propose a multiplayer mode where there are two hikers competing for who gets furthest and interacting with each other. Alternatively, one player could play as the monster and throw snowballs at the hiker.

Our physics engine also offers various extension points. One known issue with the way our physics are currently implemented is that we assume there are only vertex-face collisions. However, edge-edge collisions can occur resulting in a jittering effect when rocks are stationary on the ground due to falsely introduced torque. Although this does not constitute a problem for our bouncy physics right now, we are aware that this will need to be solved if the game is to be extended with less bouncy entities. Catto and Wheeler show how to handle this effect using collision manifolds. The idea is to consider up to two colliding points between polygons and applying a combined impulse at an average contact point of the two colliding points weighed by their collision depth.

Another way of extending the physics engine would be to add friction or air resistance. Friction can be modelled as two constants for static and dynamic friction. A friction impulse is then applied during collisions in reverse tangential direction to $\vec{v}_{rel}$. We implemented friction but decided against using it as it would currently negatively impact gameplay, which requires bouncy rocks.

Lastly, there are opportunities to further enhance the performance of the physics engine, e.g. by implementing parallel batch processing and spatial data structures.