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!

Easy Maths: Vectors

Hello there!

Today's blog is about maths, more specifically - the rather interesting side of it and what I have learned. Keep in mind that I am not an expert in the subject, so any kind of criticism is more than welcome. With that being said, let's get into the maths.

Preface

This post will cover the topic of vectors, a topic I really enjoy since I use it a lot in game development. I will show you what they are, how they can be used to draw shapes, finding out the length of them and why multiplying them together gives pretty cool results.

How to think of Vectors

I tend to think of vectors as a point in space away from the centre, think of a line that goes from the centre to that specific point. In terms of adding vectors, you could think of it as taking one string and adding it to the position at the end of the string. Or you could just quite literally add the two x's and y's together. Subtracting the two is quite self-explanatory. That is it. They are just points in space.

The power of Pythagoras'

Anyone who has ever heard of that maths question where you need to find the hypotenuse of a triangle, has probably heard of the term Pythagoras' theorem (or the 'Pythagorean theorem' if you have lived in the United States). The way they do it in school is so impractical and shoe-horned that it would put anyone off the whole thing, couldn't one just use a ruler to measure the hypotenuse? Not all triangles are right angled in the real world, in fact very few of them are.

With that being said, it can be very useful in terms of finding the magnitude of a vector (length of the vector), you plug in the X and the Y (if either are negative, make them positive) into Pythagoras' theorem and you have your magnitude!
Now that we have established that, I'll introduce you to another type of vector which is a unit vector, it has a magnitude of 1 and is useful for wanting to move in a certain direction. The way that this is calculated is by dividing both x and y by the magnitude of the non-unit vector. The result is that the two points would either be no more less than -1 or 1.

If you tested this in a game however, the movement speed would be very slow, therefore you would need to multiply it by a single number i.e. (0.5, 0.9) x 20 = (10, 18).

Geometry

Vectors can also be used to make shapes that have vertices, a good example is a triangle or a polygon. More complex examples can include 3d shapes where each vertex is a point that has variables x,y and z. The way that you can turn a bunch of points into a shape is by drawing a line from one point to another much like those drawing books which have you connecting the dots together. You can scale these if you want by multiplying the vectors by one number (similar to increasing the speed of movement). Multiplying a vector by another vector is not what I mean here, but would nicely lead into the next section.

Dot product

When I first heard of this, it was a seemingly simple idea, multiply 2 vectors together.
The formula for this is:

(X1 x X2) + (Y1 x Y2) = Dot product of V1 and V2. 

It doesn't seem too practical. How can I ever use that for anything useful? That kind of thinking is very mistaken, namely because it can be used for a lot like collision detection. A good analogy I came up with is a rod. A pretty long one, in fact one that stretches to infinity in both negative and positive direction. The direction of the rod is determined by a directional vector, ideally a unit vector, since it is very easy to measure. And there are points around it.

Here's where the interesting stuff comes in, imagine that the points fire lasers perpendicular to the rod and they are so hot it leaves a mark on the rod. To make things simpler, lets rotate this whole rod (along with the points) so they all sit in a line.

Let's get rid of the lasers and just focus on the rod.

All that is there is a rod and the red marks. The very useful thing about this is that you can compare where the 'lasers' are relative to that point using these red marks. You could use this to project a shadow from a shape to the rod using said shapes' vertices.

Conclusion

Vectors are pretty cool in my opinion, in fact they are one of my favorite parts of maths (that was, after I stopped doing compulsory maths and actually learned it 'on my own'), it makes me think about how objects are moved or what causes them to move in the first place.
Even if you never use it, just remember that you can at least view the world in a more interesting way if you know vectors.
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!

How to save and load levels

Hello there!
This blog will be about one of the most important aspects of a game's architecture, or perhaps even any kind of system (beyond gaming): loading an managing data i.e. levels!

Preface

If you've ever programmed any kind of system which manages and loads data, you may have at some point tried to figure out how to load the data from somewhere that isn't the program. Say you are making a program where you are trying to find the price of a book, you have programmed functions for adding to cart, checking the price etc, but now you need to actually have the data there. The first thing you would do is fill the data by hard-coding a bunch of values and pushing them into something like a list and run the program to see if you can check things or add them to the cart. Then once this all works neatly you would probably wonder "Hmm... how can I add items without hard-coding them in to the program"

This may not seem related to gaming at first, but it's more similar than you think.

The magic of binary

I've been dabbling around with the 65c186 assembly which was used to program Super Nintendo games (sadly I've only gone as far to make a single coloured background as of writing this). I did wonder how they included level files, did they write some kind of asset packing program to store everything into the game? Was everything all hard-coded into the game? Did the game have to access resources from outside?

It turns out that the assembly language (and other assemblers too) had a secret weapon called ".incbin". This made the question of writing asset packing programs or loading things from outside completely moot. The reason why is that the assembler did the asset packing itself, specifically when it compiles everything into one read-only memory image (basically the whole game itself). It all gets packed into one space, which makes it easy to load everything into the game, since it already has pointers to certain bits of memory like levels.

The memory is stored as a bunch of characters which may mean gibberish on first glance, but if you know what you are doing, then you will know exactly what they mean. The SNES game "Legend of Zelda: A link to the past" has a clever way of loading dialogue: instead of loading each individual word, it checks a single character and writes a combination of words based on it, for example a character with the hexadecimal value DE is "with" and E3 "you". When combined together you could write "With you" with almost a quarter of the characters needed to even write these words!

Know your files

However in something like a higher level language like C# this is more difficult. For example in Unity, you can't just have all your game in a single .exe file. There are other things that will be alongside the exe file. These may be things that Unity require to run, the part that is most relevant to this post is a strange file named "assets", this pretty much stores all the game's objects and files. Thankfully this is done when you build the game so you don't need to worry too much about it. But the difficult thing about this is that you need to tell the program where the file is and how to convert it into something that can be read, again Unity does this for you so need not worry.

Actually saving the data

What should one save data into? There are multiple answers to this question, there is the aforementioned binary conversion. One way is making an interpreter that turns level data into a text file and making a custom parser, one game of mine I'm working on at the moment uses this method. For reasons explained later, the interpreter would write the text "level:", following a series of characters. As it goes through every single object in the level, it writes to a text file each character at a time. Each character represents a different object. I also store data for the timer which writes the string "data:" right before it shows the time to set the timer. Information about the custom parser will be explained later on in this post.
Or you could use a JSON converter (Unity has this built-in to the program) which does all this work for you. First you would need to write some data structures to tell which object/data is which so you can use them later on to load into a level. You would then need to gather all the data from all of the objects so they can fill in these data structures with things like positions, type and the such like. Unity would then get to work converting all of that into a single JSON text file. Unity compiles this JSON file into that 'assets' file I was mentioning about when you build the game (turn it into an EXE file) so the engine knows where to find the file.

Unloading the data cargo

So now you've come up with a way to save data, now we need to unload it. Firstly we would need to make a content loader which checks to see any level files we have saved. Then we unload the files from binary into something we can read. Perhaps it could be a JSON file, we could write a system to convert from JSON into whatever format it was. Like how Unity has a way to convert data structures into JSON files, it can do the reverse. So we convert a text file into data that can be loaded. Great. So now what?
We would need to read from the data itself and arrange everything together based on what it says. For example if there was a list of tile data from the JSON file, we would iterate through all of them and create new tiles based on these data structures.
Or if you are writing your own custom parser, it would be a bit trickier. You would need to write a state machine so the loader would know what it is doing. For example I mentioned writing "level:" and "data:" somewhere in the text file. This is not just for show, this is so that the parser can know what section they are doing, for example when it encounters the "data:" string, it realizes "I'm now going to read the next 3 characters and convert them into an integer" so it reads for instance "015" and converts that into an integer. Before that though it would encounter the "level:" string and then would know that it is now converting every character it comes across into a block depending on which character it is.

Conclusion

Data loading is not something you would think about when making something like a game, but it is absolutely necessary (if you want to make something that can be saved, loaded and modified. There are plenty of ways to save and load data which makes it a pretty interesting topic, there are also ways to crunch and compress the way that data is loaded like the Legend of Zelda example.

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!

Easy maths: Sin and Cosine

Hello there!

Today's blog is about maths, more specifically - the rather interesting side of it and what I have learned. Keep in mind that I am not an expert in the subject, so any kind of criticism is more than welcome. With that being said, let's get into the maths.

Preface

Sin and Cosine are the concepts you may have first heard when you were being taught how to find a certain side/angle of a triangle. The phrase "SOHCAHTOA" often tends to pop up, and a lot of the questions you were given you just had to use this formula to answer them. As well as explaining what this phrase means, I'll also explain why you use this to find sides ,something your maths teacher probably never explained.

Relations with the Axis

Sine = X and Cosine = Y. I've pretty much told you the answer right there. So, next section....

Actually, I jest.

Look at the triangle below:

It has the hypotenuse, adjacent and opposite side labeled for your convenience, so you don't need to crack open your maths book.

If we want to find, for example the adjacent, we will need to use SOH (Sine, Opposite and Hypotenuse). Why?  Because the adjacent is a horizontal line, and Sine is used for working them out (think: the X axis).
Now, we're not going to do a maths question, so don't panic. I'm just telling you a theoretical example. Anyway, Sine is the thing you would use to work out the horizontal parts of the triangle. As you can imagine you would need Cosine for the Vertical axis (or the opposite in this case), therefore you need to use CAH. I'm not going to talk about TOA because I'm not talking about Tangents in this blog, only Sine and Cosine. But hopefully I've made your maths homework a bit easier. Sin for finding out the horizontal side and Cosine for finding the vertical side.

Okay, at this point in time, you may wonder "Right, I know that Sine is used to work out the horizontal and Cosine for the vertical, but why? What is the relationship between these?"

I'll tell you in the next section.

Angles to Vectors

You may have also encountered angles at some point in your maths career, the things you use a protractor to measure or what you have to figure out in a triangle, on the opposite of the right angle, (using Sine and Cosine). I'll tell you why:

As you can see, in Desmos this is what Sine (Red) and Cosine (Blue) looks like in a graph. It produces quite a wavy pattern, which looks quite nice. This wavy pattern is far more than just a beautiful little pattern, it also shows how Sine and Cosine functions, in the graph, Cosine is a little bit more delayed than Sine in terms of reaching its top and bottom, but by how much exactly, and why?

If you look below at the two diagrams, the top point is 1 and the lowest is -1, the more interesting point is the horizontal point, which is half of PI (3.142...). If you multiply this by 57.672 (to convert radians to degrees), you get a number which is ~90. Sounding familiar?

If you quadruple 90 you get 360, which a full circle is 360 degrees (or 2 PI radians). The relation of this to Sine and Cosine is that the distance that they are apart is equivalent to a quarter of a circle. I'll demonstrate what I mean below:

Make sure the setting is in degrees rather than radians.

As shown, B is 90 and the point on the circle is where 90 degrees would be going, and the number '1' is shown again, much like the previous diagrams. The reason that Sine is used for horizontals and Cosine being used for Verticals is shown in the example, due to the aforementioned separation by half a PI. If we swapped Sine for Cosine, then the point would be on the top rather than the right side and that wouldn't look like 90 degrees. Since these two operate in a wavy pattern where the highest value of Sine and Cosine is 1 and the lowest is -1, they can be a useful way of converting angles into a unit Vector. I hope you are starting to see how Cosine and Sin can be used to be turned into vectors.

This is especially handy if you want to simulate rotations via having degrees rather than vectors. 

Conclusion

This is my first time explaining mathematics to you, and I feel a bit nervous doing so, since I don't really have much of a formal background in the subject beyond GCSE. But as I've stated before I welcome any form of criticism.

Sine and Cosine are quite useful things, probably more than you thought - it can be used for things like converting angles into vectors, rotating matrices (which I know the barebones of), items that bob up and down in Minecraft or even chiptune music (stuff you would hear on old game consoles like the Gameboy).

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!)

How to make pixel-perfect graphics

Hello there!

I have been dabbling around with JavaScript on and off for a year and a half; it was not until mid-December where I decided to start development on a game using the language. I've briefly mentioned about it in my other blog posts but never really went into depth about it; I want to keep it that way until it's release (~20th February), but I will tell you that it is a game much like Prelude of the Chambered (minus the 3d and violence).

The great thing that I've learned from making this game is how to create a custom engine and way of processing logic and rendering images to the screen and the such like. I did all of this without having to use C++; although I'd still love to make a custom engine in that language, I don't think I have the experience to make a fully-fledged game engine in such a language.

What I'll be talking about here is how I've managed to create pixel-perfect graphics within the engine I've created in JavaScript.

Preface

What do I mean by Pixel-perfect graphics?

By that I mean having pixel graphics where every singe pixel is in a consistent order, like a series of tiles, with the same width, height. Usually when it comes to increasing the screen resolution, you need to make the sprites, the world and the graphic user interface bigger so that the player can see more. Many would take the approach of increasing the size everything and increasing the width and height of which the images are drawn. However this approach would produce results like this:

Not too pretty.

You can see here that the pixels of the characters are not in line with each other, there are pixels that partially overlap with other pixels. There is not much depth in that at all, perhaps if this were a game which had less pixel-based graphics like vectors, then that would be completely fine because everything else has vector graphics. But here, the cohesiveness fails miserably. You need not worry though, I have found a solution to this problem.

Drawing with mosaic

I'm pretty sure you may have seen mosaic art before, that art where each tile is placed in a square pattern. Trying to make the world seem bigger would be like trying to put a mosaic art that consist of 3cm tiles into mosaic art that consists of 1cm tiles. This may be fine if the size of the image is being resized for certain effects like this (the map below the 3 characters is being resized to give the illusion of height). However, if you are trying to make the screen resolution larger, trying to resize the images like this would lead to ugly effects like the picture below. 

The character outlines in magenta resemble the size of each pixel.

Rather than trying to force a mosaic image consisting of 3cm tiles on to a pattern of 1cm tiles, how about we shrink the tiles of that image into 1cm tiles and fit it onto the rest of the art. It doesn't have to be 3cm, it could be 7cm or 13cm or even 50cm! It dosen't matter! You can reduce them to 1cm tiles and fit them in.

Real space vs Visual space

Now that I have spent an entire point rambling about mosaic tiles, but now lets put it into practice with pixels. Say we want to put an 32x15 pixel image on to a 150x95 world, but we want to increase the size of the world so the player can see it better.

What I have learned from programming my JavaScript game is that you do not change the world or the objects' real size and position. It's a better idea to keep the two variables constant, I just mentioned the term 'real' size/position - by this I mean that the objects' size relative to the tiny pixels rather than relative to the player's eyes. Instead, you'll need to change the size at which both are being rendered, if you scale the aforementioned object and the world by 3 you will get a 96x75 image. A similar example can be seen below.

Unlike the last image of Bounty Hunter I where the pixel characters look inconsistent when they move, when you move the player in this scenario, all the pixels will be aligned or 'snapped' in place in respect to the real position of the player. The reason this is that, as I said before, despite the render size being changed, the player's real size and position stays the same as if it were if it was a 32x15 pixel image rather than a 96x75. 

With this you can have pixel graphics in a video game where they look all cohesive, much like graphics on a SNES, PS1 or a hand held console, where all pixels are displayed in a consistent manner.

Lower level graphics

If you are making a game where you have control over where the pixels are drawn, that would be even easier because you can just state how large each pixel would be and draw the character in real space and let the engine calculate the character/object's exact pixel size on the screen.

This kind of thing would be useful if you are making a render engine in something like C++, where you do not have to work around any shenanigans that a 3rd party engine may have.

Conclusion

This has been a problem that I've been consistently seeing with pixel games nowadays, and there are rarely any tutorials on these kinds of things. The tutorials I've been seeing on topics like these show things that are way too unnessacarily complicated and conboluted. I'm not sure if this is the completely right way, but I think it works. If that is not the case then please let me know and explain your soloution in the comments.

Through what I have explored here, I would like to help others encountering the same or a similar problem and mention that it does not need to be complicated as it seems. I hope this has been useful to you and will allow you to have pixel graphics that do not look messy and unordered.

That's all from me!