Tools used:
- Wacom Intuos pen & touch
- Krita
This blog is no longer in use, I don't stand by the opinions expressed in the majority of these posts anymore. Therefore you should take most of the ideas here with a pinch of salt. I'm keeping it up for archival purposes.
Thursday 30 May 2019
Prownie's art #3: Mountains
Monday 20 May 2019
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).
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:
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.
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.
Let's get rid of the lasers and just focus on the rod.
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!
Thursday 9 May 2019
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.
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.
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.
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.
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).
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.
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!
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
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
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!
Subscribe to:
Posts (Atom)