![[personal profile]](http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
In today's modern age of computer programming, extremely few projects start out with nothing to base their work on.
This means that just about every programmer, whether they realize it or not, has an immense library of code they can pull from.
Due to the cross-platform compatibility we've been striving towards in recent years, that library is even larger.
One of the many ways to think about this is to imagine that all the code available to the programmer as parts that can be connected together.
If all the pieces the programmer needs are readily available, then it's simply a matter of plugging them together, with maybe a few lines of code for each connection that must be made.
(of course, it does require knowing what to use and how they fit together, but that's what documentation is for)
Where this breaks down, however, is when something isn't handled by the code available.
When the programmer needs to write a new section of code that does more than just interface between two other sections.
This is where I am right now on my Dig Site game.
I've decided that a particular feature would be a very good idea, and would mean I wouldn't need quite so many different block types/shapes/colours as I would have otherwise.
Unfortunately, this means I'll need to add a whole bunch of code that is based on concepts that I'm still a little fuzzy on.
Namely, probability tweaking.
Up until this point, it has been entirely random what block types are added to replace matched blocks, and the likelihood of each type getting chosen has been equal.
Now, I want to make the game harder by picking block types that are less useful to the player as play goes on.
This means that I need to figure out what block types would be most useful to the player and make them less likely to show up.
Not only that, but I don't want this calculation to have much effect at the start of the game, and gradually increase its effect the longer the game is played.
It's taken me a day or two to figure out the logic needed behind the setup, and another couple of hours to make sure that the code was right.
Unfortunately, I still don't know if it's anywhere near right yet, as I'd stepped away from the computer about half-way through writing this section, and when I came back, the computer had "kernel panicked" on me.
(the Linux equivalent of blue-screening)
Fortunately, I had saved what I'd managed to complete up to that point, so I won't have to rewrite anything yet.
I'll take another crack at it tomorrow.
Also posted to my Tumblr blog.
This means that just about every programmer, whether they realize it or not, has an immense library of code they can pull from.
Due to the cross-platform compatibility we've been striving towards in recent years, that library is even larger.
One of the many ways to think about this is to imagine that all the code available to the programmer as parts that can be connected together.
If all the pieces the programmer needs are readily available, then it's simply a matter of plugging them together, with maybe a few lines of code for each connection that must be made.
(of course, it does require knowing what to use and how they fit together, but that's what documentation is for)
Where this breaks down, however, is when something isn't handled by the code available.
When the programmer needs to write a new section of code that does more than just interface between two other sections.
This is where I am right now on my Dig Site game.
I've decided that a particular feature would be a very good idea, and would mean I wouldn't need quite so many different block types/shapes/colours as I would have otherwise.
Unfortunately, this means I'll need to add a whole bunch of code that is based on concepts that I'm still a little fuzzy on.
Namely, probability tweaking.
Up until this point, it has been entirely random what block types are added to replace matched blocks, and the likelihood of each type getting chosen has been equal.
Now, I want to make the game harder by picking block types that are less useful to the player as play goes on.
This means that I need to figure out what block types would be most useful to the player and make them less likely to show up.
Not only that, but I don't want this calculation to have much effect at the start of the game, and gradually increase its effect the longer the game is played.
It's taken me a day or two to figure out the logic needed behind the setup, and another couple of hours to make sure that the code was right.
Unfortunately, I still don't know if it's anywhere near right yet, as I'd stepped away from the computer about half-way through writing this section, and when I came back, the computer had "kernel panicked" on me.
(the Linux equivalent of blue-screening)
Fortunately, I had saved what I'd managed to complete up to that point, so I won't have to rewrite anything yet.
I'll take another crack at it tomorrow.
Also posted to my Tumblr blog.
