 |
| Why I haven't asked her out. |
 |
| Gulp. |
 |
| Welcome. I'm Steve, and I'll be your Orientation Leader. |
-Kev
Tuesday, August 30, 2011
Every Day I'm Doodle-in'
-Kev
Monday, August 29, 2011
Making my little ones not-stupid.
If there's one thing a game designer and programmer should avoid at most costs it is getting too attached to you designs or creations.
Now this is not a rule, as sometimes it's required that you become attached to what you make, and becoming attached makes it better, as in terms of story lines or characters and sometimes in terms of game play features that you just know are going to take off.
But there are also times where what you have been working on, your baby, your great idea, clearly isn't working how it was supposed to you, and you have to choke back the tears and put ol' Yeller down.
For me I get very attached to my AI (Artificial Intelligence, which is a very loose term at this point, because I wouldn't consider anything I've created to be actually intelligent) and I feel as close to a father as a single 19 year old male can feel. A father with high standards, but they are my creations none the less, and I want them to succeed and prove themselves to the outside world.
Unfortunately their success is dependent upon my skills as a logic-thinking and programmer. For reference, that's like trying to teach your own kids how to sky dive or hang glide from a book because you know best. Unless you have a lot of kids at your disposal, have somebody who's experienced teach them. I don't have the luxury of doing that, however.
So what have I done, anyway, in my week off? AI coding, of course. From a very informative article, that can be found here, I first built a structure and system for pathfinding. I wish I had the ingenuity to have developed my own method for pathfinding, but as is A* pathfidning is pretty tried-and-true stuff for games (at least 2D games, elements of A* can be used for 3D games too, but there are notable differences)
If you stomached the article I provided, you can kind of ditch this next paragraph, if not, I'll explain A* (A-star) pathfinding to you in as simple terms as I can. Using A* pathfinding a network of square nodes are set up. These nodes can be listed as walkable or unwalkable. To find a path to a destination, you take the beginning node and the ending node (path start and end) and from the first node you repeat the following:
Check each of the surrounding 8 nodes for the lowest "f" score. The "f" score of a node is determined by two other factors, a movement score of the node, and a heuristic score. Heuristic is a funny word, but it essentially means a process of finding the answer or solution for ones self (or trial-and-error, if you will)
The movement score is, at least for square nodes, either 10 or 14. Moving diagonally will result of a score of 14, and moving straight up-down or left-right has a score of 10. The scores depend on the surrounding nodes location next to the starting node. Why 10 and 14? It is essentially a distance cost. Between a node directly to the left of our starting node, the "distance" between the nodes is one. but a node to the left and down one from the starting node is at a diagonal, the "distance" between the two nodes, using some simple math, would be about 1.4 (that's factoring in considerable rounding)
Using whole numbers is easier on a computer that floating point numbers such as 1.4, so we use 10 and 14. The Heuristic number can be determined by any number of methods, but I used the method suggested in the article, or the Manhattan method, which simply takes the number of nodes to get to our destination both horizontally and vertically, and then multiplies that number by 10.
Still with me?
Okay, so how does all of that help? Essentially, by following the nodes with the lowest combination of movement and heuristic scores, you will end up at the target node. It's not quite that simple, but for the sake of my story we shall assume it is.
So, using pathfinding my little minions can find there way from where they spawn, to where there target is without running into - or through - any walls.
Whew!
Oh wait, there's more.
So, what do you do when you have multiple little minions spawning and you don't want them to run into each other?
There is no simple solution to this fix, and as of now my little guys still run into each other sometimes. But I have used a method known as influence mapping to keep them from doing it too often.
Oh no, what's influence mapping? It runs on top of the node network I set up for pathfinding. Nodes are given a third score to be added to the movement cost and heuristic score. names vary, and there could actually be a number of different score-modifiers involved, but for the current purpose of my game, there's one score, simply called a cost modifier that works on "networks" (teams, essentially. Each team has it's own network on the node map with different cost modifiers, instead of using two different node maps) Influence mapping does exactly what it claims to do, it influences the path that the minions are trying to find. if several minions went through a choke point and subsequently died, do I want my other minions to go through that same point and die? No, no I do not. So how do I prevent them from doing this? Add artificially high scores to the nodes through the choke point, so that a route through the choke point becomes far more "expensive" than a route around the walls somewhere. That way, the minions can "talk" to each other. This here, this is a bad path. That there, that is a good path. (simply create a negative cost modifier, and suddenly certain nodes become excellent routes to travel through)
Soooooo... back to my point, if, when a minion creates a path, he adds to the cost modifier at each node along his path, it makes another minion less likely to use the same path as the first, preventing a good number of accidental collisions.
I now feel like a proud father, my minions are moving and finding good paths all on their own, and for the most part aren't doing stupid things like colliding with one another on a frequent basis.
I'm so proud! Now my goal is to make them even smarter, and for them not to run into each other like suidice pilots when they attack each other.
Quick, to the programming-cave!
-Kev
Now this is not a rule, as sometimes it's required that you become attached to what you make, and becoming attached makes it better, as in terms of story lines or characters and sometimes in terms of game play features that you just know are going to take off.
But there are also times where what you have been working on, your baby, your great idea, clearly isn't working how it was supposed to you, and you have to choke back the tears and put ol' Yeller down.
For me I get very attached to my AI (Artificial Intelligence, which is a very loose term at this point, because I wouldn't consider anything I've created to be actually intelligent) and I feel as close to a father as a single 19 year old male can feel. A father with high standards, but they are my creations none the less, and I want them to succeed and prove themselves to the outside world.
Unfortunately their success is dependent upon my skills as a logic-thinking and programmer. For reference, that's like trying to teach your own kids how to sky dive or hang glide from a book because you know best. Unless you have a lot of kids at your disposal, have somebody who's experienced teach them. I don't have the luxury of doing that, however.
So what have I done, anyway, in my week off? AI coding, of course. From a very informative article, that can be found here, I first built a structure and system for pathfinding. I wish I had the ingenuity to have developed my own method for pathfinding, but as is A* pathfidning is pretty tried-and-true stuff for games (at least 2D games, elements of A* can be used for 3D games too, but there are notable differences)
If you stomached the article I provided, you can kind of ditch this next paragraph, if not, I'll explain A* (A-star) pathfinding to you in as simple terms as I can. Using A* pathfinding a network of square nodes are set up. These nodes can be listed as walkable or unwalkable. To find a path to a destination, you take the beginning node and the ending node (path start and end) and from the first node you repeat the following:
Check each of the surrounding 8 nodes for the lowest "f" score. The "f" score of a node is determined by two other factors, a movement score of the node, and a heuristic score. Heuristic is a funny word, but it essentially means a process of finding the answer or solution for ones self (or trial-and-error, if you will)
The movement score is, at least for square nodes, either 10 or 14. Moving diagonally will result of a score of 14, and moving straight up-down or left-right has a score of 10. The scores depend on the surrounding nodes location next to the starting node. Why 10 and 14? It is essentially a distance cost. Between a node directly to the left of our starting node, the "distance" between the nodes is one. but a node to the left and down one from the starting node is at a diagonal, the "distance" between the two nodes, using some simple math, would be about 1.4 (that's factoring in considerable rounding)
Using whole numbers is easier on a computer that floating point numbers such as 1.4, so we use 10 and 14. The Heuristic number can be determined by any number of methods, but I used the method suggested in the article, or the Manhattan method, which simply takes the number of nodes to get to our destination both horizontally and vertically, and then multiplies that number by 10.
Still with me?
Okay, so how does all of that help? Essentially, by following the nodes with the lowest combination of movement and heuristic scores, you will end up at the target node. It's not quite that simple, but for the sake of my story we shall assume it is.
So, using pathfinding my little minions can find there way from where they spawn, to where there target is without running into - or through - any walls.
Whew!
Oh wait, there's more.
So, what do you do when you have multiple little minions spawning and you don't want them to run into each other?
There is no simple solution to this fix, and as of now my little guys still run into each other sometimes. But I have used a method known as influence mapping to keep them from doing it too often.
Oh no, what's influence mapping? It runs on top of the node network I set up for pathfinding. Nodes are given a third score to be added to the movement cost and heuristic score. names vary, and there could actually be a number of different score-modifiers involved, but for the current purpose of my game, there's one score, simply called a cost modifier that works on "networks" (teams, essentially. Each team has it's own network on the node map with different cost modifiers, instead of using two different node maps) Influence mapping does exactly what it claims to do, it influences the path that the minions are trying to find. if several minions went through a choke point and subsequently died, do I want my other minions to go through that same point and die? No, no I do not. So how do I prevent them from doing this? Add artificially high scores to the nodes through the choke point, so that a route through the choke point becomes far more "expensive" than a route around the walls somewhere. That way, the minions can "talk" to each other. This here, this is a bad path. That there, that is a good path. (simply create a negative cost modifier, and suddenly certain nodes become excellent routes to travel through)
Soooooo... back to my point, if, when a minion creates a path, he adds to the cost modifier at each node along his path, it makes another minion less likely to use the same path as the first, preventing a good number of accidental collisions.
I now feel like a proud father, my minions are moving and finding good paths all on their own, and for the most part aren't doing stupid things like colliding with one another on a frequent basis.
I'm so proud! Now my goal is to make them even smarter, and for them not to run into each other like suidice pilots when they attack each other.
Quick, to the programming-cave!
-Kev
Wednesday, July 27, 2011
I'm back!
Well, slightly.
After much putting-off and, now that my shoulder is better, a whole lot of working, I finally got back to the game, and the original game that I'm working on with David, no less. I didn't actually change a whole lot as of yet, but I've gone back and did some work on my linked sprites.
If you recall, from so very, very, very long ago I devised the system (or rather, I devised my own system) that wold allow me to link sprites together so they would rotate, scale, move and do all of that fancy stuff together. Well as it would turn out, if I wanted to link in any sort of meaningful way, I'd have issues.
Here's how it works: If one image was to be rotated, it would rotate, then it would call on it's linked images to rotate individually. Which for figure 1, works just fine and dandy.
HOWEVER, if I had a situation such as figure 2.1 or 2.2, then problems begin to arise. In figure 2.1, only the first and second image would be rotated, because the third image is attached to the second, but the second doesn't go through it's own linked list, because if it did it would also rotate the first image because the two are linked. Then there would be infinite rotation and the program would crash.
Same for figure 2.2, if they went through all of the links, each image would keep thinking "oh! I'm linked with him, let's rotate!" when they go to be rotate themselves, resulting in infinite stupidity.
The solution? Well it kind of makes sense, but it was rather frustrating to implement.
Every time an image calls for a rotation, it passes to the next image it's own personal ID number, and the ID number of the other images that the original is linked too. These ID numbers become "off limits" and if the second image tries to change any of these images, either the original image or an image that the original image will change in a later update, it is barred from doing so. Which means a few things: I can be, in a sense, pretty sloppy with how I link images. I don't have to be certain that images are only linked in a certain fashion, I can link however many I want, in any way I want and it will all be fine and dandy the minute I try and adjust even one of them. Not to say that I can just go crazy with linking images as that would probably kill the heck out of my processor, but one image can be linked to many, and they will all function properly. Any linked image can be tweaked, and all will be effected, and the game won't crash.
Later, I added in one-way linking, which I should have done from the beginning, but one-way linking means one image is considered the base, changes to the base will affect the secondary, but changes to the secondary will not affect the base. Cool? Meh. Useful? Um, sure?
The whole exercise?
Hopefully it will be of much use in the future, for the sake of this game, it doesn't change a whole lot, but it enables me to get back on the saddle, so to speak.
I work at the lake tomorrow, but hopefully I'll get some coding in!
Until next time (hopefully not so long as this...)
-Kev
After much putting-off and, now that my shoulder is better, a whole lot of working, I finally got back to the game, and the original game that I'm working on with David, no less. I didn't actually change a whole lot as of yet, but I've gone back and did some work on my linked sprites.
If you recall, from so very, very, very long ago I devised the system (or rather, I devised my own system) that wold allow me to link sprites together so they would rotate, scale, move and do all of that fancy stuff together. Well as it would turn out, if I wanted to link in any sort of meaningful way, I'd have issues.
Here's how it works: If one image was to be rotated, it would rotate, then it would call on it's linked images to rotate individually. Which for figure 1, works just fine and dandy.
HOWEVER, if I had a situation such as figure 2.1 or 2.2, then problems begin to arise. In figure 2.1, only the first and second image would be rotated, because the third image is attached to the second, but the second doesn't go through it's own linked list, because if it did it would also rotate the first image because the two are linked. Then there would be infinite rotation and the program would crash.
Same for figure 2.2, if they went through all of the links, each image would keep thinking "oh! I'm linked with him, let's rotate!" when they go to be rotate themselves, resulting in infinite stupidity.
The solution? Well it kind of makes sense, but it was rather frustrating to implement.
Every time an image calls for a rotation, it passes to the next image it's own personal ID number, and the ID number of the other images that the original is linked too. These ID numbers become "off limits" and if the second image tries to change any of these images, either the original image or an image that the original image will change in a later update, it is barred from doing so. Which means a few things: I can be, in a sense, pretty sloppy with how I link images. I don't have to be certain that images are only linked in a certain fashion, I can link however many I want, in any way I want and it will all be fine and dandy the minute I try and adjust even one of them. Not to say that I can just go crazy with linking images as that would probably kill the heck out of my processor, but one image can be linked to many, and they will all function properly. Any linked image can be tweaked, and all will be effected, and the game won't crash.
Later, I added in one-way linking, which I should have done from the beginning, but one-way linking means one image is considered the base, changes to the base will affect the secondary, but changes to the secondary will not affect the base. Cool? Meh. Useful? Um, sure?
The whole exercise?
Hopefully it will be of much use in the future, for the sake of this game, it doesn't change a whole lot, but it enables me to get back on the saddle, so to speak.
I work at the lake tomorrow, but hopefully I'll get some coding in!
Until next time (hopefully not so long as this...)
-Kev
Monday, July 25, 2011
Friday, July 8, 2011
Tuesday, July 5, 2011
Technical difficulties
The following were my emotions in the past weekend/half week since the last (real) update.
 |
| Anger |
 |
| Boredom/ lack of motivation |
 |
| Panic that summer is moving too quickly |
The problem being, is that my wrongs worked. If you recall, I linked another Dev Blog for a game called The Witness a week or so ago. I doubt any of you watched the video, but I watched the video and the writer had some excellent points about programming (from a games perspective) such as make a system that works, worrying about optimization is usually premature. Now in this instance I'm not trying to optimize... but I am trying to fix something that was only technically broken, not really broken.
 |
| Yup |
So now I must decide. Do I undo all that I have done and go back to what I had before, a working yet backward system, or forge forward with this bug hunt that has worn me down to the bone?
Tough choice.
I'll let you know what I decide... when I decide it.
-Kev
LATE EDIT:
I went through with it. As of now, I have un-reversed everything (noticeable) I'll probably be working through the rest of the stuff later.
In "celebration"...
Saturday, July 2, 2011
Subscribe to:
Posts (Atom)