Day 21
I worked myself into a corner. I’ve been spending the last two days it’s beating myself up over mostly the same problems. And after finally getting in touch with mentor about it I realize that yeah I’m not approaching it correctly if I’m doing that. I thought that it was just because I was new at programming and I made some stupid mistake that I was basically hitting my head against the wall but it has a bit to do with that designing a problem you can fix. I pretty much over complicated the problem and even if I was very skilled it probably wouldn’t be that easy to solve that way it’s just hard to see it for what it is. So aside from the fact that I’m new just need to design problems that are easier to fix. That doesn’t mean the overall challenge of completing the game is any different it just means that you take it like it’s not an insult if you can’t get everything to work perfectly the first time. You don’t need to use the complicated way and any simple way that gets it done is in fact the way that it works, can add on layers of complexity after you know that the prototype what you were doing in fact functions as you think it’s going to. So now I realized it was more not a thing about skill but just the way of asking a question so that it is easier to find the answer. It’s not that I couldn’t eventually do it working the way that I am but it’s just not compatible with getting somewhere in a short space of time. I could spend a lot of time and go into a lot more depth and complexity with the main program here and that would be fine but I really want to move on to the next chapter and since that’s my goal I really should be programming with that as my goal. You can be really easy to forget about that in between lines of programming.
At this point I don’t know which one of the things I’ve grabbed does that shader mate — variable confusion.
Oh no it’s not working it’s my fault is rather a case here of so what can I do to get a solution that covers this working. In short I was married to my scripts working out the way that I pictured them and I really shouldn’t have done that. It cost me if you’d is a programming it doing it the wrong way around. And I really do think I learned something about debugging but now with that I should be coming back and showing a completely different approach because it doesn’t need to be the one solution I thought it was going to be so much as the best solution I can find for it at that time.
In programming it is completely acceptable to break things down into smaller chunks. To paraphrase the technological race of gnomes and Terry Pratchett’s books, “How do you overcome a mountain of task? The same way you do every time, by cutting it into smaller chunks and then ever increasingly smaller chunks until you can progress through each one and then tell the amassed sum of those equals height of a summit.”
What am I doing today is the annoying process of throwing out some of my scripts. That doesn’t mean I’m putting any less effort into the overall main project it just means that some of these groups are not going to work this way. Convoluted like spiderwebs they are diversions from where I am trying to get to. And while I could fix them, it could be at my efforts would be better spent elsewhere. An example of which is starting over on those scripts from scratch — that in a dash of everything up. I’ve learned to make it go much more productively this time. the one good thing about what we’re doing here is that it’s very object-oriented I.e modular. If we need to throw out one or two pieces and we can do that without destroying or affecting, very much, the other parts of the project. We just need to up with another component that can be used in its place. I’m not exactly starting from scratch I’m just getting rid of the parts that weren’t really compatible with the current project progress horizon. I’ll probably go down that rabbit-hole some other time but right now I just need to do this and move on to the next chapter.
