Week 2 Devlog: Initial Game World, Adding some stuff!| Escape From the M'lon Factory

The Second Devlog for "Escape From the M'lon Factory!"

I'm doing this weekly for now, so it's week 2 of development.

There isn't much visual change this week, but lots under the hood! I can't wait to talk about it.

This week it's all original work, no tutorials. But it's also a bit shorter, as we are building off what we made last week.

The task for this week was to build upon the game world, building a level if you will.

But, this is an endless runner so only one level. So how do we make an infinitely generating level?

Well, unlike traditional levels, we can't exactly make an infinitely curated space so we'll have to employ the use of randomly generated obstacles and levels.  Now I'll admit I am not well versed on how to implement this but I'll come back to this soon, if it's flawed!

For now, onwards!

Now, the graphics are a bit lacklustre like last week, but I can't understate the usefulness of greyboxing! It's good to visualise systems and mechanics in a rapid setting, although I should do some colour coding in future.

Now, the main idea for M'lon is to dodge obstacles as you (the player) try to escape the factory.

Now to spawn obstacles, I've placed an object, which is always ahead of the camera and moves with it. (For unity buffs, it's a child of the camera.) Now this object has one task, toss obstacles within the game world at the player. It achieves this, by spawning in another object (an obstacle) and sending it in the opposite direction, (towards the player.) In its current state, only one type of obstacle is present and spawns at a specific interval that I can change, so I can get it right or so I can increase the difficulty.

Now the object also spawns the objects in random locations within the game world, although the way I've implemented this is a bit reppetive, I need to figure out a way to get it truly random, rather than seeded.

This is achieved by a public variable that sets the time interval, pretty good stuff. Now, seeing as this is endless there I needed a way to clean the obstacles up. If I just left them in the game world it would bog the game as it filled with clutter leading to performance issues.

How to solve this?

I thought up two options, one where obstacles are coded to check if they were off-screen, but I thought if they were spawned offscreen they would just fizzle into nowhere. (I'll need to workshop this at a later date and see if this isn't the case) as it might be a much better solution.

The solution I went with was a solid collider-based object also attached to the camera that followed behind and cleared the objects.

I'll continue to monitor this and see how it goes.

Game In Action:

Changes from Feedback Last Week:
I did some tweaking and mucking about with how the physics works, and the force and thrust.  Now there are a few issues here and there that need to get rounded out. I shall continue to try and check how it goes.

Feedback from this week:
A little quieter this week, a few things to note.
The player often catches on obstacles.
The player spins and wacks about rather than staying at a set angle, (the player can fall on their side)

I will attempt a fix this week for the obstacles and rotation. Stay tuned!

Next week:
Enemies, Interaction and Puzzles! I'm thinking about adapting new obstacle types and refining the spawner and player movement. Perhaps even a menu!