Bounty Hunter III Update #3: Area (near) completion + New character

Hello there!
Here is some more Bounty Hunter III progress.

Preface

Some progress has been going on in Bounty Hunter III, I've implemented most of the main areas into the game, progressed on the story and added in a new main character. There are also a few ideas that have been bouncing in my head about gameplay.

Implementing the environments

I've included almost all the environments that will be in the game. The way I will go around doing this will be similar to how I implemented the environments in Bounty Hunter II which is all at once, albeit with horrible and rushed textures.

Recently, I have created a map to help me envision the environment and the general direction characters may go. It looks like those overworld maps in classic RPGs like Final fantasy, Chrono Trigger, Shin Megami Tensei, etc. I have tried doing world maps on paper, but it felt much harder to do since I would easily make a mistake and I would need to constantly rub things out. I think it's easier to make maps on something like Tiled (which I used to make the levels of Bounty Hunter 1 and 2) because I can easily erase things, stamp tiles rather than having to draw every single detail from scratch.

With some of the environments, I would like them to be very spacious, allowing for open combat rather than the closed-in environments from Bounty Hunter II, where you had to fight a bunch of enemies in order to progress. Of course, I still plan there to be fights like these, especially if they are relevant to the plot, but I want to allow the player to feel more free to leave some enemies behind and maybe fight some but keep moving on.

This can give the game a faster pacing and feel less repetitive. Although I do feel that there can be some challenges in implementing optional combat like trying to not have enemies go where they are not supposed to go. I also want to make it so that the player can't just waltz out of certain areas - otherwise the immersion of a dangerous environment would be lost.

Story progress

I've been working a lot on the story of Bounty Hunter III, the specifics are more mapped out than before although they need polishing - this was achieved with the help of the aforementioned map. I used this map to jot down numbers representing the order of where the main story will take place, with squiggly arrows representing the route that the main characters will take to get to the next point. As of writing this post, I'm implementing bits of the main story into the game using a flag named "story" so that different events can happen at the same place depending on the value of this flag. This would have been impossible with Bounty Hunter II's engine, since the game is very linear. There was only one time in that game where you go back to somewhere you went before. A pretty crude method was used for this: Making a copy of the map and creating different events for it. 

Although I do write some scripts of certain interactions between the characters, I do this with the intent of seeing how the story plays out, when I write them in the game - I pretty much improvise.

Last time I mentioned about creating two endings for the game, that's now 3. Without any spoilers, there will be a bad ending, normal ending and good ending. The way you get them depends on what you do in the game, usually relating to exploration and talking to other characters. Through these I would like to reward the player for exploring with some lore and word-building, this would fit the less linear style of game I would like for Bounty Hunter III. If you have played Othermind, you will get a snapshot of what Bounty Hunter III may be like. Since I've said several times that Bounty Hunter III will be a conclusion to the series' continuity, multiple endings only seem fitting to this and I can avoid the issue of cutting multiple branches that some sequels have to their originals (like Shin Megami Tensei II).

Another bit of progress to the story lies in a new character...

Introducing Beth the hacker

For those of you who have played Bounty Hunter 2, the major characters were Peast and Milbert. I'm adding in a new character called Beth. She came from an NPC who appeared early on in the game who advises Peast where to go next. I thought that this character could play a larger part later on to give the player a surprise. A few mental brainstorming sessions later, I came up with the character Beth who is a hacker that plays a large part in the story.

Unlike Peast or Milbert, she's not going to be directly playable - because she doesn't specialise in combat. She's more of a pacifist than either of them, relying more on hacking things and communication than violence. I've had ideas of her operating snipers like Alyx Vance does in Half life 2 episdode 1 and 2 where she helps clear some enemies, Beth wouldn't operate the snipers with her hands, she would operate them using special software on her laptop.

New game mechanics?

I have implemented the code for swimming mechanics for the main character to give some variety to the gameplay. The player cannot attack whilst swimming, they have limited oxygen (if they drown, they will go back to their last non-water area like Zelda: Breath of the Wild) which could give the player a new layer of challenge as they calculate how far they can swim and try to avoid any projectiles if there are ranged enemies nearby where the player is swimming.

Another mechanic I have thought up of (and partially implemented) is rock-climbing, where the main character can scale rocks. Like the swimming mechanic, the player cannot attack and have an oxygen meter (yes I have tried rock climbing myself and it can be quite tiring). The player can jump off by pressing the jump button, they won't take fall damage so don't worry.

I don't know if any of these will be in the final game, but they seem like good additions of making gameplay have more variety. Just need to be careful that I'm not putting too much on my plate, since I also have implemented puzzles with locked doors as well so I should do something with that too. Perhaps this should be a focus that I should have with the game's design -  a mixture of combat, puzzle solving, jumping from platform to platform, swimming and climbing.

Art progress

Quite a bit has been going on in the art side of things, I'm working with my friend Joe to animate the sprites of the enemies and the main characters. I'm giving him more control here to design his own enemies, for example this one on his Instagram. This approach to art can put more bargaining ideas on the table.

He also helped me design the soldier enemies where I asked him to sketch out some concept designs which I would use to draw as a sprite. I used a combination of his concept art to come up with the final design.

Most of the game's graphics still look like utter rubbish, but I want to prioritize designing the areas and implementing the story. Thanks to the fact that I'm no longer a 1 man team, I can have some artwork done by the time the game has all the main story implemented.

Conclusion

At the moment I'm trying to implement the game's story as well as refining the it. I'll also think about coding in some of the enemies into the game. I'm hoping to get the game in a rough "playable from start to finish" state by the end of this month or somewhere around March. That way I can have more time to focus on art, sound and polishing.

In other news, later on this month I plan to post another installment to the Selfish Altruist series I've been working on for over a month now - the subject will be regarding Bitcoin.

That's all from me!

Bounty Hunter III Update #1: Combat update

Hello there!
Today, I'll be giving you an update on what has been happening on Bounty Hunter III's end.

Preface

I've finally managed to solve the hitting invincibility problem, as well as adding in a feature that will make combat much juicier. I also have a few ideas about AI and what progress I have made on the ally character that I have mentioned some months ago.

The hitting invincibility problem

The last time I blogged about Magunm foundation, I mentioned about how I didn't know how to not constantly damage an enemy with one attack. Now I implemented an invincibility timer every time the character gets hit (including the player), which is quite similar to the solution from Bounty Hunter II.
This might be a decent idea for melee attacking but for shooting, it can be quite annoying since 2 out of 6 of your bullets shot in a short span of time would hit the enemy and the rest would pass through without even dealing a scratch of damage to the enemies. Fortunately, I found a way to solve this too, which was making each attack have its own damage timer, the offended enemy's invincibility time will be dependent on the attack's damage timer.
To put things into perspective, a normal melee attack would have a target being invincible for 0.4 seconds whilst a bullet would have the target being invincible for 0.1 seconds. This can allow for a rather flexible and fast-paced combat system which can balance attacks.

For good measure I came up with another solution on top of this one: force.

The power of the force

When a character gets hurt they would enter a hurt state, when their invincibility timer goes down and where the character in question does not do anything. Before they enter the hurt state some force is pushed on to them (in the direction of the attack). This could be a pretty useful strategy for when the player wants a little bit of extra time to dodge some attacks. For the player as well this will add an extra layer of challenge as they would avoid getting knocked back too.

If you think, however that you can just constantly hit an enemy and push them off into a ditch or just infinite them with the melee attack, I have another trick that counters this problem.

With Bounty Hunter II's AI, the characters had an "AfterDash" function which would be called after a dash ends whenever it is the dash timer being reduced to ~0 or interrupted by a crash into the wall. This function was used for instructing what the AI does after a dash, determined by the state of their AI, because a lot of their melee attacks composed of them dashing.
With this one, along with the "AfterDash" function I'm also adding in an "AfterHurt" function which could steer the AI to do something once their invincibility timer is up. They might release a small attack or retreat somewhere.

This was inspired from the AI of Sly 2: Band of thieves, where they would rise up by attacking after getting hit stunned. When I played through the 1st game, most of the enemies were cakewalk to defeat as they could be defeated in one hit. Though some of them threw knives, breathed fire or did melee attacks, I would usually spam the attack button, rush over to them and they would no longer be a problem. They were more of an obstacle than an actual threat. When I started to play Sly 2 on the other hand, the enemies were much harder, they took more hits to kill and you couldn't just mash the attack button. As I've said before, they would kick themselves up, thus damaging anyone in front of them.

This would add a great layer of difficulty to Bounty Hunter III, and could also be useful to one character who assists the player.

Progress on the Ally character

I have mentioned a few blogs ago about an AI character that I was working on that would help the player on certain bits. I have made progress to it.

I added in the ability for them to attack any enemy that they are assigned to. For now, you press the 'R' key to move the character where you want them to be, you press the same key whilst hovering your mouse on an enemy to have the ally fight it and you can press the same key if you want them to stop attacking said enemy or attack something else.
The AI on this ally character is very aggressive and will attack the target relentlessly and mercilessly, I'll change this soon to a more strategic approach like running back if low on health or walking back after attacking, much like Bounty Hunter II. I may also have them notify the player to cover them using the "AferHurt" function I mentioned earlier and have them avoid any enemies.

However, it would be tedious to have to make the ally backtrack to the player if they are stuck anywhere; you would need to constantly press the 'R' key on places and wait for them to arrive. I have therefore come up with another idea to solve this problem.

Pathfinding AI theory

I have a theory of how I can make pathfinding easier: rather than checking individual blocks, I would set up a network of manually-placed nodes, so that loads of calculations do not need to happen. This can also help with AI characters going anywhere they are not supposed to.

In Bounty Hunter II I tried to have the enemy detect the last seen position of the player, but this did not go well as sometimes they would get stuck in walls or in the case of the player actually being in sight, follow the last seen position of the player rather than the player itself. Now I think it would be a good idea for some calculation to happen where the last seen position is assigned to the node it is nearest to and the enemy path-find their way towards that node rather than specifically the last seen point. Then they could preform a check to see if they player is actually there.

Story Progression

This will be the smallest section of the post, but I have actually started implementing some of the story I have written into the game. Since the game is much more non-linear than the 2nd one it could give me much more options to make the story a much more personal experience where you could talk to a number of NPCs just for the fun of it rather than going from one area to the next and having a scripted sequence happen occasionally.

Conclusion

A pretty decent amount of progress has been happening on Bounty Hunter III, combat has been vastly improved since I last wrote a post about it. Perhaps on this game, my biggest priority should probably be focusing on the AI and refactoring the game's codebase.

I recently learned how to create class libraries (thanks to another untitled MonoGame game I'm working on), which I wish I knew a year ago and would save me all the fuss of having to hop between changing this game and Othermind's codebases. To those who do not know what a class library is, a class library is a load of classes and functions which one can use in different projects without having to tediously implement its code (much like what I did with this game and Othermind) every time a new project is started.

I've created a "Magnum foundation class library" which contains all of the features Othermind and Bounty Hunter III have in common. I've also started development on a game which will hopefully be the first one to be completed and released that uses this library.

Expect in the next month to get an update on Othermind as well as a few other posts on other topics than Game Development, into another avenue which I have been quite interested in for a year.

With all that, I hope you have a good morning, evening or afternoon.

That's all from me!

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!

Announcing the release of "Ba-Temp II"

Hello there!
Today I will be announcing the release of a sequel to another one of my games, which is "Ba-Temp" which I released in late June 2017.
To be honest, making this sequel was not as special as making the original, part of this was due to the fact that I've been feeling rather depressed lately which did effect the quality of the game quite a bit. Part of the reason was because I have to worry about many things like finding a job (or volunteering), maintaining progress on my games and exams coming up the corner (in barely a month). I am trying to solve these problems and I am confident that they will only be temporary, knocking on wood. At least I have one less problem with this game out of the way!

There are numerous differences towards this game and the original, like moving the cursor with the mouse rather than the arrow keys, difficulty settings, a level-select screen and a few new blocks to spice up gameplay a little.

Since I'm dissatisfied with how this game turned out, I am considering making an episodic series (similar to Half Life 2 or any of tell-tales' games) to focus more on utilizing my custom-built level editing tools rather than have to worry about coding it. I don't know if that's a guarantee, but something I think that is worth doing - if I do, expect at least 2 episodes.

If you want to play the game, download it here.

That's all from me!

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!

Announcing the release of "Temple of Chambers"

Hello there!

This is the JavaScript game I mentioned in the last post that I was working on; after 2 months of development, it is finally complete! The game was built from the ground up, that means I used pure JavaScript functions with no 3rd party libraries whatsoever. I have been strongly considering to make another branch of this game into a game engine which I could use to make other games using JavaScript. I think that would be a wonderful idea.

Enough technical stuff, what is this game about?
You play as a big-nosed wanderer who explores a forest, when suddenly they fall into a hole which lands them into one of many chambers in a temple named the "Temple of Chambers". The wanderer needs to find their way out by solving many puzzles to advance their way through to the exit.

I initially intended this game to less linear, but it proved very tedious and testers needed to backtrack often through long corridors, therefore I decided to make the game more linear in order to prevent the need to back-track.

If you want to play the game, play it here (you don't even need to download it, hooray!)

Magnum Foundation: The foundation of a plan

Hello there!
Since exams are over, I will discuss what has been happening on the game development end. I've been working on two projects in little chunks at a time. One of them is a small JavaScript game which I plan to release (hopefully) in February of next year; the other one is a far bigger project which I have been working on since April, shortly after Red-Blue Adventures was released. This project has the codename - Magnum Foundation.

The (very tentative) plan

I intended to have this project's development started right after Bounty Hunter II, but I thought it would be a better idea to work on it whilst Bounty Hunter II was being developed. With hindsight, I feel like I may have been putting too much on my plate as BHII was mentally taxing enough (as well as a cancelled project I worked on at the time as well). Development also was not too smooth as I would encounter quite a lot of road blocks due to me overestimating my skills. However, I think I was better off doing this than having to experience all these roadblocks at a later point. Plus most of the basic gameplay features are there in a very infant state.

Anyhow, about the plan of this project: I plan to have this project create the foundation for 2 new games (hence the name 'Magnum Foundation'), one which I'm estimating a Q4 2019 release (December to nicely conclude the year as well as the 2010s) and another which I'm estimating a release in Q4 2020. I do plan both games to be sequels to previous games I have made.

Level editor

This project also contains a custom-built level editor which I try to make easier to use than something like Bounty Hunter II's fiddly one. The design of this editor looks more intuitive, as it has a save button, a brush, eraser and a object selector. The least functional of all these features is the eraser since it's quite a time consuming process to add in a way to erase tiles on a certain layer or even switch layers.
Although I do hope to fix these problems at some point in the future, I still think this level editor is functional. The best thing by far about the level editor neatly ties in to the next section.

POUCH 2.0

If you do not remember from my previous blog posts what this stands for, it stands for "Prownie's Amazingly Ultimate Cutscene Handler" (pretentions I know). I remade it with what I learned from Bounty Hunter II's cutscene handler and another open source game called "Pokémon Unity" which has a really cool looking cutscene editor which helped me make this one. It is far easier to dabble around with than Bounty Hunter II's editor as you can just move the cutscene elements around by clicking arrows rather than having to do complicated procedures and dealing with messy UI which I could not blame anyone but myself for adding in. Here is a visual explanation of what I'm talking about (along with the level editor):

I have also implemented a number of new features to POUCH like checking certain event flags (which are basically numbers) and checking items, enhanced the dialogue system to include pictures of characters. These features are essential if you want to work on a story-oriented game since things change around the player depending on what they do.

I have also created Utility events which can be activated by POUCH which I will discuss in the next section.

Utility events

These events are basically events that seem far too complicated to create in POUCH, examples can include a shop or a way to check if enemies are defeated. These are triggered by POUCH which pauses its execution to poll this event. For example if you activate a shop the cutscene will pause and bring up the shop menu.

The build I fully implemented the shop was on the 2nd Year anniversary of 'Evermoral'

 You can use the arrow keys to navigate through the menu and buy the items you want. I might talk about inventories at some point in the future (although I don't know if it will persist in the final game).

Conclusion

I do expect to talk more about this project in the future and I do plan to reveal one of the projects, in maybe March 2019 and the other one later in the year. Admittedly, I'm not sure if half of the features in Magnum foundation will make it into either one of these projects but that's the nature of creativity and knowledge work. Despite the fact that I've recently released Bounty Hunter II, I still get worried that development of these projects may wain down or get cancelled completely since these are more ambitious than most projects I embark on. But still, completing Bounty Hunter has somewhat given me confidence that I am capable of finishing such things and I may be more intermediate with the processes of creating such projects. It's also not just the workload of finishing these projects that worries me, there is also the need of balancing things like a day-job (something I honestly want to get for the experience and a bit of cash too) and also living a life, because I don't want to just spend all my time developing games and looking like some shut-in, I would also love to travel.

However, I am hopeful that I will balance all these activities, after all Einstein managed to publish a bountiful amount of thesis's whilst working as a patent clerk. This may sound cliché, but if he can do it, I could do it. 

That's all from me!

p.s.
On an entirely unrelated note, since early 2018, I've been following a blogger by the name of Cal Newport who is a Computer Science professor at Georgetown University who writes blogs about topics that are full of things that bash on conventional wisdom like. He is infamous for having no social media, yet living a happy and successful life. He is publishing a book called "digital minimalism" which centres around using less technology which I defiantly suggest you check out. Or you can read a decades worth of his blogs which will may motivate you as much as it did me. http://calnewport.com/blog/2018/12/04/my-new-book-digital-minimalism/

Announcing the release of "Bounty Hunter II" + Trailer

Hello there!
This is it, the release of  "Bounty Hunter II" a game that has been in development for over a year now, It's quite surprising how I'm finally releasing something that I have grown quite attached to and that is constantly in my head. I am grateful of the lessons and trials I have been through and learned whilst embarking on this project, even if it doesn't compete with the greatest games out there.

The most satisfying part of this is the fact that I can just finally put it aside after long hours of worrying about it, the intense work and just reflect on what I have done.
I have made a trailer showcasing the equivalent length of the December 2017 alpha, this was deliberately done to make sure to not spoil too much of the game and let players investigate for themselves.

I don't feel as exited releasing this game as I would like due to the fact that I've got other commitments like studying and working on another project which I may reveal at some point in the future. With that said, I should probably take it easier for the rest of this year so I can spend more time exploring new things, but obviously studying comes foremost so I'll put more efforts on those.

If you want to download the game for yourself then head over here: https://pixel-brownie-software.itch.io/bounty-hunter2

That's all from me!

Bounty Hunter II Update: The end is near

Hello there!

This is going to be the final post before release I will make of Bounty Hunter II. Developing this game was quite a journey, although the funny thing is that I don't really feel like I spent a year and a half making this game. The process felt quite fast, but that may be because time seems to speed up quicker as I get older (does anyone get that feeling?).

Let's reflect and talk!

Those finishing touches

This is something I had to do a lot in October (and this month) which was mostly fixing bugs with AI which made them do silly things like run into a wall, mix up certain attack patterns or attacks go inconsistently with their animations. It's one of those not-so-sexy aspects of game development but the results really do pay-off. Other times they were little animations like bullets getting destroyed, shooting muzzle etc, which give the game that extra juice. One thing I regret is the fact that I remember these things last minute which puts a good amount of pressure on me as I think 'Oh great, more animations...'. I'm not usually the best when it comes to remembering the little details, hopefully I'll get better at this stuff over time.

A second 'Evermoral'?

I'm not talking about creating a sequel to the book I published almost 2 years ago, I'm more of talking about the paralells of the two projects throughout their respective developments. When I was writing Evermoral, it changed a lot as I was writing it which would inevitably result in a lot of unused content that remained as just mere ideas.
Bounty Hunter II was quite similar, a good amount of the things in that December 2017 Alpha did not make it into the final thing i.e. the Kazzi character. Whilst the story did retain the same basic elements that I originally intended, the final story was simpler than what I would have liked. In the original story the main character's friend would have helped him throughout his quest and you could even play as him, the two would even meet this 'Mad Venom' character who appeared in the end of the Alpha who would help them in their adventure, however this was scrapped as it was too much work trying to justify why each character would leave and join the player. What I created seemed like a better idea for the player to be by themselves rather than have a bunch of other characters in their way (especially since Bounty Hunter II is a very linear adventure).

The ending was also changed several times although it does retain the same tone. You may have worked out that story-wise, working on Bounty Hunter II was not as engaging as Evermoral; I couldn't create as much of a world where characters could interact with each other. In the latter, I could easily convey the character's personalities by just writing stuff and re-iterate parts I didn't think was good enough. With the former however, if I wanted to create a compelling story, I would first of all need to make a bunch of tools to not make this process completely tedious (which is an absolute pain in the arse) and go through a bunch of steps to save the level it is in and test in-game to see if it works or go in the way I would like. Bounty Hunter II's story was not as deep or philosophical as Evermoral (although even then some parts of Evermoral's story was flawed), but I have realized that making a game is different from writing a book upon writing this post. You can't just go and say "I've got a game idea! Let's make it a reality!" because you need to consider things like "Okay, does this fit in a game? Does this compliment the gameplay in any way, or just filler?". This process is something that 2016 me would have not even expected.

Although I have been a bit negative, let's go to a more positive side of the coin. Despite the fact I couldn't create much of a deep story in Bounty Hunter II, I gained a very valuable insight on how to create a event system that you can easily mess with and make stories with. I liked the process of creating something that I can use to edit cut-scenes rather than hard-coding the events. The optimization part was the coolest part of it as it makes me think "Oh yeah, I could do that instead of what I had previously done!", it has also gave me valuable lessons on how to create an even better tool in the future. I suppose sacrificing the story for this experience isn't too bad, it makes my analytical and creative thinking go hand in hand.

Conclusion

Bounty Hunter II is by far the most ambitious game I have made, as well as the longest I have gone in terms of having a game with a story and dialogue. With that being said, I don't know how to feel about finishing it, do I feel accomplished or not?
Maybe it is one of those things that I might appreciate later on or maybe I need more of a life.
All work and no play makes jack a dull boy, no?

But I need to balance my studies at sixth form as well, and maintain decent grades. Although I honestly don't care about A-Levels (I might write a blog about education at some point), something in my mind is pushing me - as well as that I don't want to disappoint the head of sixth form or my parents.

I will be sure to keep you people updated though, in the meantime expect Bounty Hunter II to be released around 21st of November.

That's all from me!

Announcing the release of "Earl's Order" + Trailer

Earl's Order release

It's finally that time to announce the release of my latest project "Earl's order". I've been working on this game for 3 months and a bit, with the main intent of teaching myself the A* algorithm. I thought that making a game with game-play elements from Fire Emblem (whilst obviously putting my own spin to it) would be a great way to give weight to this concept.

I've also made a trailer to this game which merely demonstrates the kind of game-play this game will have.

Plus, there's also a secret I've put into the game when you beat it, play it to find out...

That's all from me!

Bounty Hunter II Update: Art completion and cutting out.

Bounty Hunter II Update: Art completion and cutting out.

Hello there, I've got another update for you, a lot has happened since the last time I've updated about this project.

Art
Over July and August I have been working hard on the character designs, and I'm glad to say that for the most part they are finished. The enemies no longer have placeholders on them, they now look fully unique and more alive. However I did encounter a problem with the animation system. Unity has a built-in animation system which operates like a state-machine, which was a problem since I've had to create constant parameters every time I want to create a new animation controller (per character) and the animations didn't work the way I liked i.e. character takes 2 seconds to switch to the shooting animation.

I created my own animation system which switches to a set of animations (up, down and side) via a number. This worked out much better as the transitions were far faster.

In terms of the tiles for the levels I spent later August and this month completing them, and I have just completed them as well as replacing all the levels' placeholder tiles, I'll give you an example of what the process was like below:

Before polish

A boring-looking green area

After polish

A lush jungle

I'm not going to show all the areas because that's spoilers, but this is what I did for all the areas. On top of that, I had to not only give it crispy looking graphics, but I also had to redesign certain areas. If you see on the top image it had tons of small rooms where enemies would be fought. One tester even told me that I should make the areas that the player fights enemies bigger, the image below reflects my response to this feedback. Instead of making the player constantly enter clustered areas where they barely have space to dodge attacks, I've merged several small areas to make one large area (you can see above) to make use of the game's mechanics.
Some areas still might be needing a bit more polish, but overall they're pretty much done.

However, with that being said, I've faced a few regrets with this way of designing levels and making animations. I did all the animations and tiles in the last few months of development, last time I did mention about how I wanted to do animations after I design levels. Now I think this isn't the best idea. Ideally I should have done animations after I programmed the character's actions into the game, to save time later on. It didn't matter if they weren't polished, what matters is that they are at least something and polishing them can become less stressful as a result. Perhaps for future games I should consider doing art at an earlier point to make production as consistent as possible, but try to not have them get in the way of debugging the game.

Cutting out features:
I have done quite a bit of cutting out lately, I've cut a number of areas in the game because I didn't really like the design and it felt like pure padding to the game, trying to polish them gave me more work to do and I think that my time and elbow grease would be better spent on creating the areas with good potential. I also cut out one boss, despite almost everything being done (including the artwork). Not to sound lazy, but I decided to cut him out because I didn't want to face the extra work of balancing him and implementing animations into him. Plus one of the testers said it was quite hard. Maybe I'll look back to this and regret what I've done... but you know, that's part of any creative process - not all ideas end up in the final product.

In the last post I mentioned about an ally character, now he's removed from the game. This is because of, again extra work (animations) and developing the AI was quite a pain. Now despite what I've just said, these were not the main reasons that I removed him; it was that he didn't fit with the game and felt like an obstacle in the main character's path.

Maybe if I ever make "Bounty Hunter III", I might go a bit further and implement an ally, if they fit in with the game. That could be a possibility. I'm working on another game that may help me tackle much of the issues I've faced when implementing an AI character (more detail on that at the end of this blog).

A few Extras:
Today I've added an after-image effect when the characters dash, I added this in because the player/enemies dashing without it wouldn't be as effective. I actually found other uses for it too, for example it can indicate when an enemy is dashing towards you.
Here's the dash in action:

Looks cool doesn't it?

The other day I've also added in a fade-in effect when the player exits out of a map and goes into another. I wanted to make it so that the fade-in happens then the game loads the level and it fades out once it's loaded, but I've been having a few problems with it so I should sort that out.

Conclusion:
The game is near completion which is both exciting and scary... scary because I feel like a simple error might completely blow the game up.  so I'll need to go into crunch mode and rid any bugs along the way (hopefully get it in beta by late October). I strive to get this game out in late November (hopefully slightly before Evermoral's 2 year anniversary).

In other news I've also got another game in the works that I'll release about a month from now which I've mentioned in my last post. That game is quite close to completion so hopefully little should come in the way of that game releasing.
Well, maybe... except school, this year's pretty crucial so I need to get my act together and update my revision summary to do all that dirty memorizing work for me! Study hacks for the win!
Hope you guys have a good morning, afternoon or night.

That's all from me!

Bounty Hunter II Update: Single focus + Refractoring

Hello there!
It's been over a year since this game has been in development (around 5th May 2017), boy does time pass quick!
Here's an update on how things have been going on my end with Bounty Hunter II.

Refactoring NPC/Enemy code:

Upon adding an ally, I went into a problem
How this started was that I was trying to add in a character that accompanies you for a little bit. Obviously I'd need to add in AI; naturally, I went to the enemy codebase to copy the code. However I realized that this was pretty rediculous. Why do I need to painstakingly copy and paste code just to make an Ally character?

It was then I decided instead of an enemy codebase, why don't I do a NPC codebase?
This allows for me to create NPCs which can be BOTH enemies or allies. After a bit of thinking, I came up with the idea of  a faction system - a system which dictates what characters attack whom. Without having to rewrite another type of NPC, I can just assign the ally character to the same faction as the player and they'll be freinds. Easy! I can even make the NPC an enemy if I wanted to.

There is also another benefit to this system - I can also make the enemies have their own goals beyond just trying to defeat the player. To those of you who have played games like Half life (or Half life 2) you may notice that zombies and marines/combine soliders are both enemies to the player. However the zombies also attack the soliders and vice versa. This gives the game's world that extra depth to make the enemies not all monotonous. It's like you are living in a world rather than a video game.

Minecraft also does this to a certain extent with some hostile creatures attacking some passive creatures, but not as well as Half life.
Although I don't plan to do too much with this system, it does give me some insight if I want to make a more complicated/mainatianable NPC codebase. Perhaps this could lead me into making Skyrim (I jest).

Maps:

It's one thing to make enemies, it's another to make maps. Before earlier this month I designed levels like this:
Design map -> Add collisions -> Code nessacary enemies (if needed) -> add enemies into the game -> Add events -> Finish map -> move on.

After then, I realized that this method would take much longer and the perfectionist way simply isn't the best for the development time of this project. I'd probably struggle on designing one level and be stuck on it. Therefore, in the crunch of a week, I decided to finish all the maps the game will need (11th of May to be more specific) but have them void of any cutscenes or enemies. After this I then focused on adding in the remaining enemies (which incidentally took more or less time to implement). I also added in most of the bosses the game will need other than the final boss (the first form is complete).

After I add the remaining boss into the game I will then focus on actually adding them in to the levels and create the events the levels need like story-based and boundary-enabling. I like this way a lot more than the former because it can give me much more time to playtest the levels and seek feedback from others months before I expect it to release.
It can also give me time to work on other projects (which I'll get to in the conclusion) since I don't have to focus on implementing but rather polishing what's already there.

"Trap" objects

I wanted to find a way to make the game more varied than just run n' gun. Because to those of you who have played the public alpha (which incidentally, the itch.io version I decided to take down because I wanted to hide it until release), the gameplay consisted of going across the level fighting enemies to make boundaries disappear in order to advance. Thanks to these objects which I call "Traps" you can do slightly more than that.

By traps I mean objects that the player collides with that damages them in some way. For instance one type of trap is a trap that is much like a ditch (well, it's essentially that actually), which damages the player and teleport them to the position before they fell into the trap. The way to avoid this is to dash across the trap, much like the player is "leaping" to another platform. There are some which do the same, except they don't teleport the player.

I try to use these to give the player a break from combat and get them into good ol' platforming, because hey, why not?
Plus it gives the dash an extra use apart from a useful way to dodge endless waves of leap attacks and bullets.

Conclusion

This is all I'd like to say for now about this game, anything else would be a spoiler. Despite the game's development going pretty well (knocks on wood), I still do get a little bit nervous about whether it may be completed or not despite this game being over a year in development.

I've had experience with more ambitious projects like these, where I'd have some big idea for the game for example a game version of my old book series "Ratchet and Sinro", and dream up how the game will look like.
However, in month (or two if I were lucky) or less I'd procrastinate and completely forget about the project, leaving it in an indefinite hiatus.

With retrospect, it's a miracle that I've been working on this game for this long and I've never had that procrastinate-ish feeling; sure I've had doubts about it's success but I think that's a good thing.
It shows that I've still got lots to learn before I can become something rare and valuable to the world.
The difference between this project, I realized, was my more realistic expectations - I didn't have some pre-existing and specific thought about making this game.

I just thought it would be cool to make a sequel and did admittedly come up with a few ideas (like dashing, because dashing is cool), but they were mainly developed further through experimentation, slowly moulding into a different form of what I originally envisioned. As a result, some ideas that quickly came into my mind were dropped as soon as they came, as I worked on the game.
It turns out I enjoy the reality of the features I added in, more than the ones I came up with in my head.

Anyway, enough deep talk. Changing the topic slightly,
I've got some other neat stuff outside of Bounty Hunter II to show in the future, I'm not going to say what they are but I'll give you a hint:

• One of them is a riskier project than Bounty Hunter II.
• The other uses a new custom language I've made called "Pixel Brownie Text Markup Language" (UPDATE: The latter has been cancelled due to lack of direction)

Both are major projects like Bounty Hunter II.

For now I don't have any minor/side game projects in development.
Although I would love to make some right now, I'm in a very awkward situation, trying to balance school and Game development (it's not easy!).

With all that said,
That's all from me!

RedBlue Adventures: Crash n' Brawl - Released

It's finally out...of the development table! And into the huge ocean of games.
Another completed project under my belt.

Download here:
https://pixel-brownie-software.itch.io/redblue-adventures-crash-n-brawl

If you want to give a opinion on the game you can fill the survey:
https://goo.gl/forms/decdj4rlAnVCzKK13 (I promise it won't take long to fill in)

RedBlue Adventures: Crash n’ Brawl Update!

Hello there!

I have good news:

RedBlue Adventures: Crash n’ Brawl is finally feature complete!
(on 24^th Febuary to be exact)

Feature Complete

This phase of development is quite a hopeful one, as you’ve created a finished product – now all you need to do is refine and tweak it until it’s good enough to be released. But the funny thing about releasing something is that you don’t feel that sense of happiness that you did when you dreamed of releasing it. It’s more like “Okay. I’ve shipped this product, time to move on to the next thing.”

Whilst enemies/players are relatively easy to add in, buttons were not. I didn’t include a function to add them in due to the whole add listener function which basically adds a function to the button. So I had to deal with copy-pasting this many times

Yuck

Elurgh!

Positioning them in a row was also a pain, as I’ve also had to initialize these variables (can be seen on the right) every time I wanted to do so.

As well as this, there were plenty of times where I had to botch efforts to fix bugs. Workaround after workaround after workaround.

But at least this taught me to write better code next time I work on an RPG.

Playtesting

At this point in time I’m getting people at school to test my games for a bit, and it’s quite valuable as they give me feedback and I can analyze how they play. It seems that in the beginning that they didn’t know what to do. I’ve been writing a list of notes to show what improvements the game needs.

I think it would be quite helpful if I can get some people online to playtest my game, you can note me on deviantart or email me on ratchetandsinro@gmail.com if you want to give the game a shot; I’ll send you the build.

You’ll also be prompted to fill in this form (which is mostly multiple-choice): https://goo.gl/forms/decdj4rlAnVCzKK13

I’ll try to do this for every game that I make, because play testers are very nessacary to a game’s development. Not only for the game at hand but I could also learn what the world truly depends on or at least wants from gaming.

Summing up:

RBA will be coming pretty soon – somewhere in mid-march so for those who want to playtest it, playtest it ASAP. And be sure to fill that form too – there’s no point of testing if you can’t give feedback!
Well… you don’t have to but it would be invaluable information to me.
I couldn’t ask for anymore!

That’s all from me!

Bounty Hunter II Update: Level + Cutscene editor

Hello there, it has been quite a while since I’ve updated about this game.
However the lack of updates do not depict the whole entire picture of how development has been since I released the alpha… well maybe a bit.

I did add in a few levels here and there, but I’ve focused progress on trying to refine the game. Not only what the player experiences in the game but what goes on in the development scene. Last post about BH2 I talked about making some new level editor because I didn’t like the old one. And the old editor was becoming a pain to use, so I decided to take the risk and create a new one. From scratch.

Level editor

I spent a good amount of January making and refining this editor. Heck. Even on the day I’m writing this, I still have some hidden work left to do on the editor. And I can say it is far better to use than the old editor – it’s nothing you’d ideally want to work with, however it’s good enough for me to cruise through level design in auto-pilot.

Let me explain how:

-          I have created a slider that allows you to easily allow you to switch between levels, in the old editor you had to change the number by hand, which gets pretty tedious.

-          Levels are stored as little bits of data consisting of arrangements of certain objects i.e. enemies, cut scenes and objects; instead of folders containing the prefabs themselves this object loads one prefab like a boundary and according to the data it contains, it manipulates its size and position. This means I’ll only have to change the boundary (or any object) once. This saves me plenty of the slog of having to manually edit every single instance of the same object.

-          In the old editor, every time I wanted to add in a new position I would need to manually add it to a linked list of positions (which the index of those positions is loaded in respect to the current level number). Now the level object (that is loaded) contains the positions of the player’s spawn point and if I want to change the players position, easy! I can just alter the player’s position in the object, no need for all this tedious looking though index monkey business.

-          Recently I added in a feature that can just place any object depending on where your mouse is and the game does all the work of which segment of the level data to assign it to, saving me a lot of grueling work I had to suffer through when I made the December alpha.

Level production is much faster this time around, however it is still quite slow because as I’ve said before I’m still working on this editor and good levels require lots testing and polishing. Not to mention the other things that require my attention i.e. rewriting less maintainable code, writing AI, play-testing, creating cut scenes.

Cutscene editor:

Creating cutscenes.
I’ll mention about that next. At some point I considered making a cut scene editor but refused as I thought it would be too hard. However as I successfully made a level editor, it surely wouldn’t hurt to make a cut scene editor, right?
Well I was initially right, because I’ve had quite a lot of trouble making this cut scene editor because there was a lot of stuff I had to do. Now it’s near-complete, I can make cut scenes easier than I could before.

Before I had to deal with a load of variables showing up, and it was quite messy to work with.

Now with the new cutscene editor - only the needed variables show up if I want to edit a dialogue or a movement. At least I didn’t take the inane route of hard-coding every single scripted event that happens in the game. I’ve learned far too well from developing BaTemp that hard-coding things that clearly don’t need to be hard-coded can be very slow, dull and tedious.

It’s always important to not only work hard, but smart too.

Object pooler:

This is more technical than the last two, but it deserves a place in this post nonetheless. What an object pooler is:

A system that allows objects to be pre-created into the scene and put in a ‘pool’ and disabled. Once the object needs to be there i.e. an enemy shooting a bullet or heck, even the enemy itself, the needed object rather than giving the engine the instruction to create a new object, is instead taken out of the ‘pool’ and enabled. Once the object is gone/not needed, it is put back in the ‘pool’ and once again disabled, further awaiting it’s time to come.

“Why is this efficient?” you may ask, “Dosen’t it lag the game with far too many objects?”

No, since they’re disabled.
But here’s the main reason why – if a robot shoots a bullet, a good amount of people would think “Obviously we’d need to have a bullet created! How else is the bullet going to exist” which is fine… except when you have say –  25 (let alone more) robots all shooting bullets at the player, each individual one being created and destroyed. At this point the game engine will be thinking “My goodness! This is a whole lot of work!” as it constantly gets panic attacks trying to get multiple requests to create/delete objects, thus lagging the game and lowering the performance.

However with object pooling, it is nice on the processer – the objects are already made, all the engine needs to do is just enable the desired object in the pool and pop it into the game. Thus creating much less lag and performance is high.

It’s still being worked on though, and I am incorporating it into the level editor.

Artificial Intelligence:

The AI has had many revamps too. In fact this is my main focus right now, as I thought that may have needed some refactoring. Funnily enough this whole notion that I had to improve the AI came from developing the 2^nd boss in the game. I wanted the character to feature some AI to be challenging, however I had some pretty tedious code on how AIs do things so I decided to change the overall code which definetly made things neater.

In fact I came up with an entire library of AI functions which any character can access, so I can add in AI a little bit easier.

I’m still working on it and looking back at the code I have far too many regrets on how I did the AI. It’s quite messy, but you live and learn. Hopefully with these ideas in mind I can make AI in future projects better.

Summing up

Much apologies if I haven’t focused on anything that wasn’t technical. But in all honesty – you can’t go through game development without focusing on the technical stuff. I’m trying my best to do some progress on this game so bare with me.

In the meantime, I would like to share some very cool news about RBA in my next game development post.

That’s all from me!

Bounty Hunter II Public Alpha

The alpha of the game is out and available in the hands of fellow gamers!
Keep in mind this is not final and is subject to change.
Let me know what you think of the game!

BH2 Updates

Hello there!

It's been a while since I've updated anything BH2 related!
Apologies for that, but there is good news to be had from this: Progress!
A lot actually.

Let's get to the bitty gritty shall we?

POUCH

"Wait" you say, "What has 'pouch' got to do with a game where you run and shoot things?". A lot actually, cutscenes in particular.
POUCH (Prownie's Outstandingly Ultimate Cutscene Handler) looks a bit like this.

As you can see it is not the most tidiest of systems at the moment but it's still easier than hard-coding every single line of dialogue and movement etc. This brings me on to what the heck this POUCH thing is.

It is a custom-made cutscene making tool that I have built myself.

It originally started as something that just sprouted dialogue, but thanks to my increased skill and confidence in programming, I decided to make it do more than just read dialogue.

It also moves characters, spawns objects, fades the screen in and probably most cinematic things you can imagine.

Combat + AI

There have been plenty of changes to those, especially AI.

A few months ago, I sent an early prototype of the game to a play-tester I met on Discord.

He commented on how there was no need to dash in the game, a game-play mechanic which I thought would have added lots of depth to the game. He also mentioned that players would always go for the more easier and boring route to completing the game by kiting the enemies.

I decided to play thorugh the game without ever dashing, and funnily enough.
I was able to beat it.
Easily.

You could be a complete newbie at video games and be able to beat that clear, one shot and boom!
Done! You can now throw away the game into a nearby rubbish bin and forget the fact you ever played it.
(Please don't do that to the final game. I crafted it with my heart and soul! Criticism is welcome though).

He was right, I could just walk back whenever I saw the enemies or heck even stand in one spot and just spam the shooting button until they die.

Because in that prototype the enemies just walk towards you and if close enough they stop to attack.
They don't shoot or lunge or do anything that would need you to dash out of harms way.
They're lacking... quite a lot of what makes good AI.

So one day I decided to create a room exclusively for combat purposes and alter the enemy AI. I first of all decided to give the enemies a lunge attack. And I tried to playtest the game without using the dash.

Within the first few 30 or so seconds I died from the enemies' attacks.

A small light shone in my heart as I first saw an ounce of challenge burst through this very figment of my combined efforts.
Now the dash was becoming something useful.
Not too long after I found out that you could actually use the enemies dash to your advantage.
Let me explain.

When the enemy uses their dash attack, you can actually dash simultaneously right through them, then emerge behind them with a mill-second to spare to blast their brains out with your trusty Peacemaker.

Yeahhhhh...

Actually, I've got a name for this: The trade blow.
Because you essentially trade positions with the enemy and shoot them right away.

It might sound simple or trivial on paper but in practice it is not as easy as you think.

Timing is an essential ingredient to getting this tech right ; if you don't dash as soon as the enemies do, the enemy will be the first one to lunge at you with all their might and power.
And you are going to have a bad time.

I also applied this to the boss of the area (yes, this game has planned multiple bosses, not just one like the first game). He is harder than your average enemy but he is quite a good way to mess around with the combat system, since I don't want to reveal much about him (since I want you to explore it for yourself) I won't talk about him very much.

The last thing I want to mention about the combat is a more minor one. You can cancel dashes by pressing the shoot button. This can be quite useful if you want to keep your fire range close to the enemy rather than dashing to the other side.

I'm still skeptical about this feature since I haven't found too much use for it.
But then again, I think I'll need to play-test the game a lot to see where this feature works the best.
And make any necessary changes to make this feature more useful or ditch it entirely.
Only time will tell.

Animations

I have spent a lot of last month working on the animations, and for a large part, they are complete. They are a huge step-up from the RPGMaker2003 styled 3 frame animations that the 1st game had. The animations feature detailed and clear walk-cycles within each character.

Since my game "Pipe Dreamer" I have come up with a new way of animating sprites, I basically separate the body parts into segments and animate them. Then I put them together to make an animated sprite.

In my opinion this works far better than drawing every frame from scratch because, let's face it:
There will always be that off-chance that you may say "Oh dear! Where's the position of the torso at this point of the animation?" once realizing that you have made a wonky animation.
It has definitely helped me not only make more efficient animations, it helps me make them faster.

Isn't life easier when you break it down?

Level Editor

To make development easier, I've decided to make a level editor for myself.
It loads level layouts from a list and displays it all.
This is quite revolutionary for me since in the first game, all the areas were in one scene.
Part of what it does is generate enemies and collisions based on an arrangements of specifically coloured pixels.

But there is a downside to this, if I want to edit a collision box on an enemy or implement an animator on to them, I would need to click the Generate tiles button to generate them again, I might need to find a workaround but I won't focus on that now.

The feature is sound so far though, nothing game-breaking. Ideally I would prefer to make an editor where you can place enemies, collisions, cut-scenes and all that stuff on the go and save it all to a specific file, but I don't think I have developed enough skill to do that.

Perhaps I may create a better editor if I ever create Bounty Hunter III.

Summing up

Progress with Bounty Hunter II has been going pretty well as of lately. I have been spending a lot more time and effort on this game than I did with the first game so hopefully it should be better than the first...
I hope.

I'm planning to get a playable prototype by December so that's something to look forward to.
It's going to be pretty short, and I mean short. But that isn't always a bad thing, since I prefer shorter games as the replay value is higher.

That's all from me!