Dev Blog

Update #1


Leaving the school project vibe behind us

Even though we’re working hard on the sequel called ‘We Were Here Too’, we haven’t forgot about We Were Here. Now, six months after the release, the game is still being played by more and more gamers worldwide. So we thought it was time to give the game a performance upgrade, allowing more gamers with lower-end setups to enjoy our game. Read all about how we achieved this as our programmers Sam and Thomas explain the fine details.

Since We Were Here started out as a school project and had to be developed in less than three months, there wasn’t too much time to optimize properly. Shortcuts in code were taken, unnecessary amounts of polygons were drawn and multiple lighting systems were stacked upon each other. Four major goals were set when starting with this overhaul:

  • Increasing overall performance (Especially for lower-end systems)
  • Less hiccups / frame drops
  • Solving frequently reported bugs
  • Preparing the game for future ports to other platforms

Spreading the load

A seamless game experience is an important part of the game. Upon entering the actual gameplay phase just after the matchmaking, a system called Dynamic Mesh Filter System (DMFS) was developed to simply split up different parts of the game (e.g. the theater and dungeon) and only enable those where the player is walking. This makes game-breaking loading screens in between puzzles obsolete. However, toggling large amounts of game objects at the same time caused hiccups as well. To improve this system, Sam redesigned it from scratch. He came up with an asynchronous recursive depth-first traversal algorithm that essentially spreads the load by enabling game objects within an area over time. In the example video you can see the player walking through the dungeon. As he walks past corners, the DMFS starts loading the area he is heading towards, and disabling those he left. This improved system, together with Occlusion Culling, makes for a smooth gameplay experience