The split of two games + exclusive core features

Hello there!
I've got another update on Magnum Foundation. Today I'll be focusing on the issues of splitting the game into two halves as well as some of the core functionalities I've implemented since the last update.

Preface

There has been quite a large amount of progress since the last relevant post, although since then I have split Magnum foundation into two projects, I'll still call it Magnum foundation until I reveal one of the games it contains (around march).
I've also added in a number of features to both games like options of placing tiles, modifying collision data and teleportation. Splitting the game was quite a hard decision to make since I've had to deal with a number of consequences which I'll get into detail in the next section. 

Splitting Cautions

Which time to split the two projects was a pretty hard decision to make, on one end I could try to split early so I can start to focus on adding new exclusive features to the two games. On the other end I could try to focus on building up the core features that would be present in the games I would be making, then I could go on create the exclusive gameplay mechanics and features on each project after this stage is done. Both have advantages and disadvantages.

The former has the advantage of me building up the core exclusive mechanics faster so I could actually spend more time actually making the maps and programming/designing characters for the game and possibly refractor the game's code much earlier. However there is a disadvantage to this, which is that if there is a feature that is fundamental in both games, I'd have to spend time implementing it from one to the other and it would eventually be quite bothersome having to hop back and fourth between the two projects. And this is despite the fact that the solution could be to just copy and paste the needed code.

The latter has the advantage of me having a core solid foundation to base both games on, thus elevating thus eliminating the need to constantly hop to-and-fro between two projects. However like the last point, this also has its own set of disadvantages. For one thing I would need to refractor the codebase because by "laying a foundation", I mean adding all the features that both need in a very FYS (functional yet shoddy) form.

In this case scenario, I have two options - I could either spend even more time on refactoring the existing codebase or split the code as is and have to do the shift-fixing anyway. If I just planned for the two games whilst working on/polishing the foundation for them, there would not be a guarantee that these plans would be the same, because it is one thing that you plan and another to implement (and test) these features.

Furthermore with building the foundation of the two games, it will never be perfect especially since it is the first time I've made games of such scope (think: A short Zelda game/ Cave story). How could I possibly know what needs to be done on my first go? Yes I've worked on some similar games, but there is always something you don't know about when you have stepped into unexplored territory.

Maybe if I make games of this scope after these, I will be far more certain of what I know I'll need when it comes to such things, thus making the split less of an issue. I know this because back when I made "Red-Blue Adventures", I knew much less about developing RPGs and would often run into many bugs that I wouldn't have even thought about. If I made a game like it now, I would make the codebase far more clean and easier to mess with.

Map transitions and collisions

In terms of teleporters or map transitions, I've had experience with mostly ones that take you to the next area and teleport you to only one place. The teleporters in Magnum Foundation are significantly different, they teleport you to certain positions that a map has in its data. Originally I did want to do something like what they would do in RPG Maker where you can just click on where you want to teleport to on the selected map, but this proved to be far more time consuming and harder to do than I thought. Therefore, I decided it was best that I put objects which names you could link to a teleporter that teleports you to that object.

For example, say that I have map 'X' and it has these linking objects. I could have a teleporter in map 'Y' that links to one of map 'X''s linking objects, perhaps with the name 'FromBuilding'. Once the player touches that map transition in map 'Y', they teleport to Map 'X' to the object with the name 'FromBuilding'.

Collisions are far more customizable, as the collision system was written from scratch (using some help from Sebastian Lague's tutorials). Since this is the case, it became far easier to implement a feature where collision tiles do not apply to a certain type of character, so they could just pass through. This would have been handy for Pipe Dreamer's development where there are certain tiles (i.e. water) that could only have been accessed by certain characters. Using Unity's default Rigidbody 2d in these situations can prove to be very difficult as I'd need to constantly fiddle with workarounds and the such like resulting in a large mess of code.

Although some may argue that this is 'reinventing the wheel', at least you know the wheel you're working on.

Layers and tiles

Another thing I would like to discuss is the level editor, more specifically the layering and tiling system.

My experience with making maps/levels for my games would either be using some 3rd party tiling programs like 'Tiled' or making my own, which would be reading from a pixel image with certain colours, for example, Catwalk or Bounty Hunter II (when it was early in development). More recently with Waterstone Temple, Earl's Order and later on Bounty Hunter II, would have their own custom-built propetary level/map editors.

The first two had their tiles built up as a database of every single tile's position and type. Bounty Hunter II's maps were created in Tiled, then exported as a large PNG file (with separate layers), the rest of the information can be found in an earlier post. Since it can be a bit memory-consuming to have a large PNG file (feel free to correct me if I'm wrong on that), I decided with Magnum foundation to take a more different approach.

I decided that Magnum foundation would have the approach of using Unity's built-in editor... editor. This allows programmers to extend the Editor to make it suitable for their own needs. I did do this to an extent in the 3 games I mentioned before, but Magnum foundation uses it to a much larger scope. I did analyse some code from a Level editor that was related to pokemon and decided to create my own level editor based on it. Unity does have a built-in tilemap, but after some serious consideration I decided to make my own from scratch.

The reason I've decided to make them from scratch was to learn how to make my own tile map editor as well as having more control over it. If it's buggy then I only have myself to blame rather than try to wait for an update, as well as that, I'd need to deal with fitting the tilemap into a format my game can read. As I said before with the collisions, at least I know the wheel I'm dealing with.

Conclusion

Progress has been going pretty well for magnum foundation, I've been working consisntently on it on this past month. I haven't mentioned all the features I've worked on because I don't want to blather and overwhelm you with a big load of changes. I might mention them as this project goes along in the development pipeline, possibly when I've expanded on them.

That's all from me!