Yea as I walk through the valley of the shadow of derp . . .

The internet is littered with dead blogs. I myself have made a few, perhaps you have too. When you start learning a new subject, your enthusiasm lights you on fire, and you feel the need to share your progress with the world, to share your joy at grasping new concepts, finding new paths, inspiring yourself!


And well you should. However, I think it's also important to document your down days and moments of despair, because everyone who works creatively has them. After all, what is the value of the creative artist if he/she is not a person who can walk up to an unfamiliar problem and immediately start coming up with, if not solutions, then at least ways to approach the problem that transform it from a mysterious bogeyman into a an abstract problem that can be approached, reasoned with, maybe bargained with . . .


You may have gathered from this, or from the lack of screenshot this week, that my "Skeleton Wizard" platformer has run into difficulties. Well, it's true, and if this blog is good for anything it should be good for exposing the weaknesses that cause bright-eyed indie game devs to plow straight into the earth at hundreds of miles per hour.


Now, this problem is probably trivial to most anyone who would be going through the back issues of some self-taught nerd's gamedev blog, but try to imagine instead that you are facing a problem that would stump you. And if there is no such problem, please close the tab and go f . . . ind something else to do.


Wizard walks and jumps on blocks. Kindergarten shit.


First time out, I got a class Block, which when called into being as a live instance is going to have some set attributes regarding its size and texture/appearance. Note that calling Block does not give the block a position, it just means that the game, at runtime, is going to create and gather a bunch of these objects that are examples of the for "Block" which is going to have some characteristics common to the Block class. My Game1 class has an array of these guys called blocks[], with its array length set to a static variable called iMaxBlocks, which is set to, whatever, 10 in this example. iMaxBlocks being what we'd call a "static member" of the class Block, a variable attached to that class that won't change and that will be the same for any instance of that class we decide to conjure up.


I apologize if this is so basic as to be worthless; there are probably lots of blogs by real, competent programmers that you could read. This blog is by a dude who had to re-take high school geometry, and the hope is that my hapless machete swipes through the field of game development may point the way for interactive media professionals even stupider than myself.


But I digress . . . The problem with blocks[x] is that I haven't given my Block class the same kind of drawing and placement "infrastructure" that Tile has . . Tile being based on a tutorial for tile maps allowing the designer to create levels using a text file with comma delineated lines keyed to cell contents, like a line with a small platform might read


'.''.''.''.''P''P''P''.''.''.'


or the like, which is basically a crude level design tool, and thus immediately attractive, but I am quickly faced by what must be a fundamental problem: how do I integrate the data structures I am using to draw these maps with the data structures I am using to check player collision with blocks - they are different and something has to give.


More on  this when I figure it out . . but if this post has a point, it's this: the "hardness" of "unsolvability" or "fuckthisishardness" of a given problem is not an inherent function of the problem. To a chicken, starting an automobile is an "unsolvable" level problem, while for a human it is trivial. If, when facing a problem that does not have an obvious point of entry, you cast yourself as the chicken in the chicken vs. car keys scenario, then of course you will not succeed. Find a framework, or a window, or a perspective, or a viewpoint on the problem that casts it into a place where you can work with it, like you would cast a (float) into an (int) if you had to.


OK maybe I've made my point.