Othermind Update #1: Reverting to pre-made

Hello there!
Progress has been recently picking up a little bit of speed lately, I'll tell you why.

Preface

Remember last update, when I mentioned about the fact that I was running into problems with making my own custom collisions? I ran into more problems than I had initially thought so I had to scrap everything I made and revert to Unity's built-in Rigidbody 2d. I also switched part of the level-editing into Unity's Tilemap, due to performance reasons. I have also made updates to PUPPET (Pixel's Ultimate Propeitary Placement Editng Toolkit), which will probably make my life much easier when I put in collisions.

Custom collision colossal

Yes I have made an alliteration. I couldn't help it.
I was trying to implement the custom collision system I talked about last time, but there were a lot of strange problems that I had. For example the character would keep jittering all over the place when they detected a wall and keep teleporting back, sometimes the character would be pushed through the wall they were supposed to be pushed back by. I would spend days trying to figure out a decent solution, and when I actually them in to the game they don't work out.

By this point, if I kept tackling these problems, I would spend more time doing that then actually making the maps of the game, characters and polishing the game (which are more important). I then decided to give in, and switch to the built-in rigidbody. I may have less control, but I don't have to worry about having to refine collisions in the long run, I have used it for a lot of the games I've made in Unity so its always a reliable back-up option.

Not saying that I can't make separation collisions a reality, but in Unity making your own can be frustrating. Especially if you have the rigidbody2d right up the corner begging you to use it with its diverse functionalities, tailored to any kind of game. If this were something like Monogame, I would have done this much easier, although the only game by far I have made with it (Catwalk), does not feature separation collisions, the player gets pushed upwards instead if they touch a wall.

I'll make a blog soon about how to make these kinds of collisions a reality, just to confirm that I'm not showing off. Honestly, they took me the longest time to figure out and I'm aching to share it with you.

Anyway, I've also changed how the player interacts with certain collisions that determine things like falling, ditches etc. Rather than being objects spawned in the scene they are kept inside the map data. There is a calculation that goes on to round the player's position to the position of the 'objects' themselves, so when it is rounded it checks the player's position relative to the objects, if the two's positions are equal, the offended collision preforms its function. Rather efficient, I'd say.

Overfilling the scene with objects

When I try to test the game, I have to spend a good minute waiting for the engine to load, why? Because the object pooler has to spawn a lot of objects. A lot of these objects were decoration tiles, which I have added in to the game to give the world some texture. I have found out that these were probably what consumed a lot of time, since the pooler has to spawn over 300 of these on startup. This is quite large relative to every other object like triggers and entities which have about 5-20 of each spawned.

This is when I decided to use unity's built in tilemaps to cover collision areas and visible tiles. The whole system seems so much more efficient than mine, it was much faster and did not create so much objects. It has given me much less stress now, so I can actually focus on designing levels, which I will talk about later. The fact that the other aforementioned collisions are also not spawned can save performance too.

Scribbling to fill need not apply

In terms of my custom level editor, I have written a flood-fill tool which covers an entire enclosed area. I eventually got sick of scribbling the whole enclosed area by hand, especially as the editor kept slowing down, having the mouse movement lag and thus making me have to move the mouse slowly so that I can draw the areas more accurately.

The way the algorithm works is a bit like A* but far less complicated, the full explanation for the algorithm is beyond the scope of this post. Although in the previous point I have discussed that I use tilemaps for loading collisions, I still use my own tools for saving collisions due to the fact that there are also the different kinds of collisions which I've described about several times on this blog.
But at least I have learned something cool! And that's what counts.
You never know, I might use this on future utilities (like something using the Windows Forms library).

Level production is starting to come in

I've been starting to slowly put more focus on adding in levels, so I don't have to worry about implementing them later on. One goal I have for what the areas will be like is that they will all feel somehow connected to each other, like in the original Pipe Dreamer where certain areas would transport you to other worlds. Banjo-Tooie has this as well, where you can transport to a sectioned-off area of another world from one world. It gives these areas a very inter-connected feel to them, they aren't' just a bunch of random areas strewn to a hub-world. It's also a convenient way for those who can't be bothered to go back to the hub area to go to another.

At this point I have also implemented all of the controllable creatures from the first game, albeit there were only 3 (one for each world). There will hopefully be much more than 3 in this game, there will also be more than one type of character for each world, some of which are hostile to the player.

Conclusion

Development is slowly starting to catch up now, as I'm starting to worry less about trying to implement my own stuff. This is especially important since I've set myself about half a year to finish this game, I think I should spend more time at this point at refining the game's code, like the event system, level loading and character physics and the such like.

I've got exams in a few weeks (thankfully only two timed ones, both from History). As of writing this I will probably be working on my graphics exam which is done before study leave (after 17th May). I've done my photography though. So development might be a bit slow for now, but hopefully it should pick up soon. Lately I've also been experimenting with other tools as well like Monogame and Windows Forms. I'd like to make another Monogame project soon, I enjoyed using it when I was developing 'Catwalk'.

That's all from me!