Project details - SC-SGS/surviving-sarntal GitHub Wiki

This page aims to explain the goal of the project in more detail.

The main challenge in a game like "Surviving Sarntal" is that user-interaction requires for real- time rendering and real-time physics. In this project, we address the second topic, i.e., real-time physics.

Real-time simulations are only possible by drastically simplifying reality. To start with, "Surviving Sarntal" sets up a 2D world. Thus, the rocks that fall unto the terrain are modelled as simple rigid circles with different radius. The models for rock-rock and rock-terrain interaction are very simple, and include ad-hoc solutions, such us capping the velocities to a certain value. Currently the physics system is coupled to the frame rate. In fact, the time step is the inverse of the frame rate. As a result, the physics implementation is subject to the frame-rate, which prevents from choosing the time step freely and compromises the modelling.

In this project, the real-time physics in the "Surviving Sarntal" game will be improved. The students will implement 2D physics as realistically as possible, without compromising real-time.

For this purpose, they will decouple the simulation time-step from the frame-rate and improve the models for the rock-rock interaction, rock-terrain interaction, etc.

In parallel to the main task, the students will be faced with game engineering challenges and research software engineering questions.

The tasks to be addresses during the course of the project can be grouped into 3 work packages (WPs): research software engineering, modelling physics and game engineering.

• WP 1.1 Set up protocols in the repository
  E.g., decide on branch protection rules, CI/CD workflows, formatting, etc.

• WP 1.2 Setup a documentation platform.
  The documentation will have to be updated iteratively during the project.

• WP 1.3 Refactoring of the code.
  Which is the best architecture? E.g., object-oriented instead of ECS architecture? This will

  be decided through an iterative process with WP2.

• WP 2.1 Decouple physics from frame-rate.

• WP 2.2 Improving physics.

  Asses and improve the collision detection algorithms. Look into rock-rock, rock-terrain, and rock hiker interaction. Can we get rid of the artificial capping of velocities?

• WP 3.1 Review game design.
  Ensure that there are no design inconsistencies within the game, e.g., flaws in the main loop or in the item functionality. Apply the necessary changes to tie up all the loose ends. 
• WP 3.2 Update game according to new features (if appropiate).

Based on the project description, we decided to document our vision for the project in more detail.

What is our goal?

• natural physics (no rotating or floating rocks, no glitching through terrain)
• smooth terrain (splines?)
• constant frame rate, decoupled from physics
• usability / portability (executable / Docker ? )
• maintainability / extendability \item smooth gameplay (e.g. movements with acceleration,...)
• game visuals (start screen, hiker sprite)
• fun gameplay (upgradable items)

What do we have to do to achieve our vision?

• dev environment and workflow, pipeline with executable at the end
• clean code / conform to styleguides
• documentation
• OOP (or ECS or mixed?)
• model of current software
• specify architecture of our refined software
• leave physics more or less unchanged
• understand graphics
• tests

• Research simulation methods
• decouple frame rate from physics
• decision discrete particle simulation vs analytic solution
• rigid body simulation (rock-rock, rock-terrain, rock-hiker interactions)
• no capping of velocities
• terrain creation (dynamically configurable, x-problem solved for possible caves in the future) – hiker-terrain interaction
• particle simulation for visual effects
• smooth hiker movement (acceleration)

• start screen
• items and coin system
• visual update (hiker sprite)
• scoreboard (name system), maybe global
• any further features
• caves, interactive terrain (quicksand, ice)
• increasing difficulty of terrain (with different visuals, snow, ice, fire)

After finishing the project, we reflected on how much the game developed and changed in the course of the bachelor's research project.

A detailed conclusion can be found here: Conclusion and Reflection.