Magnum foundation's two games + Priotity troubles

Hello there!
I've made some progress towards the two games although they are somewhat minor. In this post I'll also be revealing the two games. Without further ado...

Preface

Just before I reveal the two games though, progress has been a bit slow with them due to me not knowing which features to priorities. It's a bit of a mess at the moment, but I'll get to that later on in this post, now I'll reveal the two games.

The reveal

One of the games I'm working on is "Bounty Hunter III" which I plan to release in late November of next year (2020), I intend this to be the final installment to the Bounty Hunter series. This motivation came from wanting to finish what I've started so I can move on to something different, and Bounty Hunter is no exception. Should I decide to make a follow up, it will be with different characters and continuity, whilst retaining core gameplay mechanics and some enemies like the yellow snakes.

The other game is called Othermind, a sequel to a game called "Pipe Dreamer" which I released in summer 2017. I thought that a sequel could do the first game justice since I've improved my programming skills, there were more than enough features I could think up to do this sequel justice. I plan to release this in December of this year, a little tight, but hopefully manageable.

Exclusive features

In terms of Bounty Hunter III, the game has a half-functional combat system which I've started to garner more attention to. I have been working more on trying to facilitate the existing features and test out certain scenarios like shops and cutscenes, as well as creating new collision types. The most interesting feature I can mention here is an ally character who helps the main character in his quest. Though I won't reveal who they are, I will mention that you can have them on three modes:

Automatic: The character follows you and fights any nearby enemies. I have not implemented the latter yet).

Semi- Automatic: The character follows walks to wherever you click in the order of where you clicked first - this can be useful if you want the character to attack certain enemies, press certain switches and so fourth, much like this. In terms of targeting certain enemies, let alone the aggressive AI, I have not implemented that yet.

Manual: The full control is transferred from the player to this character, this is probably the feature I may scrap at some point, because you can accomplish a lot of what you can do in the Semi-Automatic mode. Maybe I'll change my mind but for now, this mode will probably not make it far.

I know... the graphics look rubbish here.

I did try adding in an ally into Bounty Hunter II, but it did not fit in with the game's story so I scrapped it. There were also a lot of considerations I had to make like whether or not the ally was vulnerable or not, as well as trying to make them be able to transverse through the map without issues. This time, the ally is much more involved with the story so it would be more likely to be a feature I take further. I've also realized that I can design maps that are tailored to what the AI is capable of, since I'm not planning them to appear in all parts of the game (a hero always needs moments to himself, doesn't he?). This would save valuable time since I need not stress about thinking "What if this situation happens?" all the time. I could just make the AI capable of several specific things and leave the rest to scripted events.

In terms of the combat, I've made the main character have a melee attack (something that was not present in the predecessors) which is pretty much like shooting a bullet except it doesn't move and appears for only a split second. This may seem simple on the outside but I'll explain the problems I've been having with this in a later section.

Moving on to Othermind, the possessing mechanic makes a return where you shoot a beam at a character and you take control of it. This one does still retain elements of the first game, for example there is no combat or a solid story. The difference between this one and the first game is that it is not set in a dream world, but rather a strange island.

There are some returning creatures as well as a palethora of new ones, some of which are hostile towards the player and will knock the player out for a bit when in contact, or in the case of the Player possessing a creature, they will be de-possessed. I was originally going to add hostile creatures into the original but I didn't know how to implement them in, questions like "What if the player is possessed? How will they know that a certain possessed creature is the player?" or "If the player de-possesses the hostile creature won't they be knocked out upon de-possession".

Fortunately, I managed to answer both of these questions with this installment: The manipulated hostile creature will be knocked out upon de-possession, this will allow the player to escape (if the creature is hostile) and not get knocked out. But being knocked-out is more of an annoyance rather than a way of a threat very much like Wario Land 3.

Changes to the level editor

There were a few changes I've made towards the level editor, for example I've categorized brushes depending on which layer is selected. The reason you select layers is so that you can place certain objects into them via brush. This makes life a lot easier since the game saves levels into chunks of layers like tiles, triggers, entities, decoration tiles, etc. For example it wouldn't even save a trigger if it was on a tile layer, it needs to be in a trigger layer or else precious time creating the events that pertain to the trigger would go to waste.

The game also has a specific way of loading each layer from the JSON files (the format of the game's save files), so that is also important to keep in mind.

Previously, I've had to be careful of which object and layer I had to select to make sure it does not create a million copies of itself on the same spot. An example of this is putting a trigger into a tile layer, since it is not classified as a tile and the extra code, that checks if an object (in the layer) at the position of the cursor exists, wouldn't even pick on the object.

Now when I select, for example the tile layer, the brush menu shows all of the tiles so I know which blocks I can use on which layer.

Another change is implementing level sizes, this may sound silly at first, but I didn't implement a level size. The reason this could be a problem is that if I wanted to implement something like a flood fill (so that I don't have to hover my mouse everywhere just to fill a certain area), the algorithm wouldn't know when to end so it would keep filling everything until Unity crashes. I haven't fully implemented a flood fill yet, but I am doing so as I'm writing this post, but I have the theory that this tool will do me good later on.

A few obstacles

At this point I've encountered a lot of difficult obstacles, for example the collision system, I've been encountering a lot of issues with the characters sticking in the walls and not managing to get out. There are also the issues of the different types of collisions conflicting each other. I'm in the process of rewriting this system and replacing it with a much simpler one (resembling Temple of Chamber's collision system) because as far as these two games are concerned, there probably won't be any kind of advanced geometric collisions or advanced physics systems.

This might sound a bit lazy, but I'm trying to save time so that I can reduce the amount of workload I need to do (which is still a good amount). Maybe I might make the collision system more advanced as Bounty Hunter III goes along in development. In terms of Othermind, I'll most probably keep it the same.

Earlier I mentioned that I had issues with melee attacking, I'll tell you exactly what I mean. When the main character attacks once, a single invisible "bullet" should appear directly in front of when the player attacks. Much like a bullet, when it touches an enemy target, it detects the enemy and damages it accordingly. Where the problem lies is exactly how long the bullet should stay for. Because if the enemy has 20 health and the attack does 1 damage, if the attack lasts for one second and detects the enemy every single frame, it would die immediately.

The solution to this issue would just have the attack appear and disappear after one frame. This way it deals one damage every time it is summoned out. That may seem fine, until you get into attacks where one character charges. The attack hitbox should be on at all times or else it would be a bit silly if the offender passes through the offended without the latter taking damage, however if the hitbox was there at all times then all the enemies on the path would die due to the immense amount of "On hit" functions being called every frame.
A potential solution would be to put an invincibility timer on the characters. The player/Ally? Fair enough. The enemies? Well, it wouldn't be fun having to wait for them to become vulnerable after waiting a few seconds. A solution to this could be reducing the timer on the enemies, but even then, if several bullets (i.e. a shotgun) hit them at the same time - once one hits the enemy becomes invincible allowing the other bullets to pass through.
As you can see, it's quite hard deciding things like this - I've had this same problem in Bounty Hunter II and sadly it was never really fixed, although I made the shotgun's bullets penetrate the enemies on impact.

I'm also not sure which feature I should put on a top priority or when I should start creating maps, hopefully it should all come together soon though.

Conclusion

At the moment, it does seem like development is a bit on the slow side as priorities keep changing from time to time. But I'm trying my best to prioritize which features are the most important to develop. It does help to simplify some features which seem quite unnescacary at the moment (i.e. geometry based wall collisions), so I can focus on the features that matter more.

That's all from me!