Tuesday, June 16, 2009

Turning It Up To 11

That's my problem - 11. The number after 10 but right before 12. The number that appears rarely on guitar amps. The number, that controls whether or not enemies will back away. 11, is the problem.
Yesterday I spent most of my night trying to figure out the why of it. Basically, it goes like this:

"I'm standing around, and I'm not doing anything. I think I'll back up, and nope, fooled you. For real this time, I'm still not doing anything and now I'll...got you again. Hur hur hur. Standing, Standing, wait for it...Standing! Silly you."

This will continue until you exit the program or the universe is taken by heat death, whichever comes first. Since the regular randomizer didn't seem to give me the result attached to the number 11, ever, I told it to make every outcome 11. To, turn it up. In cheeky response it did, well, the thing right above there. I then proceeded to install a wide variety of tests, and notes so the code would tell me something, anything really, that would let me divine the core problem. I'm sorry to say that after 1-1/2 hours, I still don't know.

Further, the whole problem is exacerbated by the fact that my code in this area, is jumbled. It's said that the city of Venice is built on top of the old city and that one was built on top of the older city and so on, until eventually you get down into mud full of Roman junk. My AI code is like that. As I went, each piece works by itself and is stacked on top of the last piece, all the way down.
Oh, and the syntax sucks. It's like it was written by a retarded baboon that typed in the code using only his big, blue ass. Commands nested in commands, that only work when the moon is right and the game is being played by the eigth son of an eigth son of and eigth son.
So, since I can't seem to figure out the root cause in a normal way, I must conclude that the problem is systemic. Today I'm rewriting and, more importantly, re-ordering the AI code, so that it will fall in line better with how the damn thing is supposed to work. Something like this:

If eState = 7
Do Stuff
EndIf

If eState = 8
If EnemyAttack > 0 and EnemyAttack < 7
Attack things
EndIf

If EnemyAttack > 6 and EnemyAttack < 9
Block Things
EndIf

If EnemyAttack = 11
Back the hell up
EndIf

EndIf

Then, maybe, it'll work. I can't see what can possibly go wrong.

-In something else, I had another discussion about the games as art thing. I've made my position clear on several occasions (they're not) but I was thinking, "Other than logic and what I think a game is, is there a specific reason that I think that way?" The conclusion that I came to was that I need to.
I'll explain. Basically, I argue that any (good) game can be reduced in some way to its most basic parts. When I do that I find that everything is expendable except the mechanics. Hence, a game is defined by the mechanics, defined by the rules of play. As I've said before, rules are not art. The reason that I feel that way, is because the mechanics are what I deal in. As a Designer, the mechanics are everything. The game can have anything on top of it provided that they either serve the mechanics in some way or do not hinder them. The mechanics are the meat. Everything else is sauce.
Granted, some people play games for the sauce. I don't have a problem with that. But my games are not designed to hold sauce, and they never will be.

No comments: