AI_targeting debrief

First, who would have thought that one small component of AI behavior for my game would have taken so long to get working?

I was on a good roll, making steady progress on my project for most of December. Then the holidays hit and I couldn’t work on the project as much as I wanted. I had also just started to run into some stuff that was a little tricky (not that it was really hard, just that it was new to me) around this time, so the lack of putting time into it also made me feel nervous that I’d get stuck. There’s no way I’m ever giving up this project until I complete it, and that’s that, but I’ve run into problems in the past with projects where I get stuck, don’t know where to turn, and it sucks a lot. Oftentimes that puts the entire project at risk. But this is a project that I’ll never accept failure on — I’m working on an idea I had 30 years ago, and if it’s been in my head that long, and not gone away, it never will.

So, into January, I had less time than I hoped to get back into the project. When I did, I wanted to make the time productive, so I tended to pick things that I knew I could do, and that needed doing, but not necessarily the thing I’d gotten stuck on. That’s OK, but normally when you see something is going to be hard for you to figure out, you should wade into it and tackle the problem. I didn’t do this with myself, so much as I tried an idea a little bit, and when it didn’t do what I was expecting, I put it aside again and worked on something where I had more traction. I had a fatalistic sense of “When I am ready for this to make sense to me, it will.”

Also, during a lot of this time I was spending a lot of my project time on reading documentation, not coding. It was a struggle to make sense of what I was reading. My mind kept tripping up on something that didn’t make sense to me, and which in the end turned out to be inaccurate (unless I *still* misunderstand something, but I don’t think so). So that wasn’t too helpful.

In the reading that I did, I discovered a lot of things that merited further reading, and had to trace down a lot of avenues that potentially could have led to my solution, but didn’t. This wasn’t wasted time, though, because a lot of that stuff may end up becoming useful later, and having a clue that it’s out there is going to be helpful down the road.

Ultimately, I was able to prevail over my problem, get un-stuck, and deliver a working proof of concept. I need to do some further work to turn this proof of concept into an extension that I can import into any future Game Maker project that I work on, and from there I still need to bring it into my game project. But that’s all academic, and I have no doubt that I will get it done, and so I’m able to confidently declare victory at this point.

My initial attempts to implement the solution I was after focused on doing it directly in the current game project. I’ll call that a mistake now. For one, the existing game already has a lot of stuff in it, and the complexity of it makes it difficult to see (or think about) any new problems clearly. I had several false starts which ended up failing, trying this way.

Eventually, I got to the point where I recognized that what I needed to be able to solve the problem was simplicity. So to get that, I started a new project, and threw into it just enough bare bones to provide me with the building blocks I needed to test out the AI code that I was trying to figure out how to write.

So I did that. Twice. The first time was almost right, the second time was right, at least so far as it went, and I’d figured out enough to know that what I’d built there would work for what I need, but I need to do the rest of it back in the main project. The first attempt help me to figure out what I was doing wrong, or rather, what I needed to do.

So, that exercise was very beneficial. The second attempt only took me about 5-6 hours of hacking away at it to get it to work, which is about par for every other feature that I’ve committed in the project so far. So the fact that it took a few weeks of thinking, procrastinating, reading, and trying various things doesn’t worry me so much. I know the next time I get stuck with a problem like this, I’ll get to the solution that much sooner because I can take this general approach to it.

What was the most useful for me in solving this was the stuff I built into the project to provide me with feedback so I had something to diagnose. I strongly recommend building instrumentation and logging capabilities into whatever code you write. Otherwise, you’re only able to see what you can observe from the outside, which often ain’t much, and is apt to be very confusing when the application is behaving in some bizarre, unexpected way that you can’t figure out based on what you thought your instructions were saying to the compiler or interpreter.

Leave a Reply