It doesn't really matter if mankind is on the edge of extinction, all you really care about is taking some good time before everything goes black.

https://ldjam.com/events/ludum-dare/41/the-hole-at-the-end-of-the-universe

Relax. It will all end soon.

Hello everyone, I am glad to announce that the game we built during the ludum 41 is now finished and released on the Google play store !

If you own an android and wanna play our short game, feel free to give it a try ! We will appreciate any feedback and hope you will have some fun and not so-frustrating time !

Despite the will of making an isometric game, we finally decided to make a UI based game, using Unity. We started working on it at 7h30 UTC+2, and quickly agreed on the idea. We were 5 persons to begin with, 4 now, with one graphic designer, two developers and one game designer.

In "Experimental Treatment", you will be able to live as a voluntary medical guinea pig, testing out new pills and trying to cure your own diseases. However, the pills you will try might have unexpected results, and you have to make sure that your organs do not stop working.

We are using collab, mostly because Git is too uncomfortable with Unity. We took some time making JSON deserialization to allow non-developers to generate data we could use for the game without the need of using the Unity software.

By the way, if you happen to have cool names for fictional medicines, we need those! (Generally related to lungs, muscles, heart, brain or intestine)

We decided to base our game on a screen wrapping feature to match this game jam's theme, but its implementation wasn't as straightforward as expected.

Using Unity, playing with screen borders was far from impossible, but still took some time.
We opted to use trigger colliders to know when the player went out of bounds, but we had to change dynamically the size of that collider for every window resizing.
Fixing the aspect ratio was also important, otherwise players with different aspect ratio would have different ways to finish the puzzle levels.

Player teleportations had to be smooth; we did not want to have a blind spot where part of the player could not be seen.
One thought we had was about using cameras to focus on the part of the player we needed and print it at the right place; but given the many unknowns we had about such a system, we went for a simpler system.
We created fake characters to display when straddling two or more screen borders. After a while we decided to always keep 9 characters existing, separated by the screen height and width.

By teleporting the player when he went entirely out of bound, we were sure we would always keep all needed character models in screen.

We still have to take care about the collisions: the 9 characters could not use collisions at the same time, but by activating only the colliders visible on screen, the relevant collisions were present. The only special case was when only one side of the screen ended on a wall: to avoid a character appearing within a wall, we created an invisible collider to simulate the wall on the other side.

Overall, what made the feature harder to control was the player controlled camera. By choosing to allow camera moving, we added a more original feature to create richer levels, but also encountered a few buggy situations.
Fortunately the game ended up being playable, and building the prototype around that feature gave a pretty satisfactory jam game for us.
Here is the link if you want to play "Blank Tape"

After several game jam coming across gameObject reference error, it was time to do something about it

With a few developers and integrators working on the same project, every game jam we encounter a few recurring issues:
- Someone adds a new feature with new prefab(s) in the scene. Other scenes lack the prefab, and game is broken - A gameObject that references another gameObject from the scene loses the reference: the script breaks

One root cause links them all: a script (MonoBehaviour) references an external game object from the scene.
Maybe this is a SerializeField that we drag and dropped. Or a FindGameObjectsWithTag or Find to fetch an object. But at some point, the reference is used, and there is nothing behind.

Those habit we had ultimately fails to achieve one key concept: making a modular software, where systems do not directly depend on each other.

Before the jam, I was looking for some pattern we could use when creating our Unity game.
Thankfully I discovered that talk from Ryan Hipple and his article, which made me realize it was possible to build your game around Scriptable Objects.
If you run across the same issues as we did on Unity, I highly suggest you give a look at the article (and the video if you have the time).

What we ended up with is a game where every interaction between our prefabs was made using Scriptable Objects (SO). Suddenly all our prefabs could live independently. When we need to interact between different gameObjects, we know we have to rely on SO.
- Variables that are used by multiple prefabs are now stored in a SO that lives outside the scene and that will never raise a Null Reference Exception.
- Function calls between multiple prefabs rely on SO as well, using some generic event SO that can be emitted or listened to (using an observer pattern)

Here is the kind of design (or, should I say, absence of design) we used before:

And now, making sure prefabs interact only through SO, it is closer to this:

We tried to apply that architecture this game jam for the first time, and we are quite satisfied with it. We still have improvements to make on the generic classes we use as a basis for our variables and events, but it definitely helped us achieve a stabler game this time.
I hope this can help some other developers!

Lastly, we would be grateful if you could check out our game Sol Invictus. See you next jam!