2-27-08

Even though there has been no diary update, which is odd since this takes a lot less effort than the code, I have completed a bunch of work on the code itself and we’ll do a quick rundown and the stupid crap that happened.

-Got the include code to work for the level loads. It works out really well. In C++ include files do a bunch of nonsense and have to be included as boilerplate code*. What I never managed to understand was how to build them correctly and then include them. Anyhow, with Blitz Basic, all I do is point the code at a different blitz file. It would be like putting at the top of this diary : include: yesterdays post, and then having yesterday’s post appear magically at the top. The really nice thing is that the included code doesn’t have to work by itself, which comes to my next point. I included the level information is a separate file (so it’s not in the engine proper). Specifically, the level info does not include any of the useful code that allows it to run, like, at all. In effect, it’s nonsense gimp code that I don’t have to worry about too much.

-In other news, I started to understand more specifically how the include code works. Here’s a cute trick that does (work): Save a text file and rename it with .bb on the end. You can then include it! It’s great! This means that I can save a file out of the level editor as anything I damn well want, including a .bb file, and the code will be natively recognized by itself. This is good news for the level editor proper, as well as when it ships with the game itself. As long as the files are saved in the Player Created Levels file, then it should run all by its lonesome. That’s so nice.

- The include file for the levels, is also why, oddly, there are fewer lines in the new code.

-The deflect code works, and it works pretty well. It has a window of about 10 frames or so. It works when you’re paying attention, but it isn’t needed to win. You just have to be better at blocking. Also, in an odd turn of affairs, I can’t seem to get the lower one to work, for me. The code works fine, and when I turned the FPS down, I could get it every time. Heck, even the timing is the same, but I can’t seem to do it as consistently. Oh well, I guess I’m not very good. I also set the code up so that it can be changed depending on the enemy type, so the different enemies will all have a different rhythm to deflect them at. So if I wanted to be a pain, I could have someone fight a few different kinds in a row, just to mess with them =D.

- There is now an Action Button instead of 2 different keys for everything, but I may have included that already. Now however, the attack key is tied directly into the deflect code. So now I have, 1 button combat, but it actually requires quite a bit of reflex to work. The combat, after all, is twitch based, not tactical, so the 1 button thing actually works and allows you to focus on the more important aspects, like not getting your clock cleaned.

-Today I smashed an AI bug. Sometimes, when you reach a screen with an enemy, it would be stuck at it’s Limit, and flicker right and left and not move until you moved into it. So that was dumb. To fix it, I simply changed the code to be less/greater than or equal to the limit to switch it around and walk the other way. No more flicker.

-Back to the levels. I brought home some of the levels I did at work (getting a great sense of accomplishment by the way. In effect, I was getting paid to design levels.), and started putting them together by brail (no TheifEd) and getting them to work. 3 things occurred to me.

1) The game is actually quite fun to move around in. The levels all change like they are supposed to and the enemy works. The movement feels really good.

2) The movement is far too big for the levels I designed and the screen itself. It wasn’t an issue with the test levels I built, but as soon as I got to some honest to goodness gameplay, I realized the Thief jumps too high, runs too fast and the dash goes too far. So I need to reconfig the movement again. Still, this is good tweaking that will make the gameplay much better in the end and allow for a greater variety of level challenges.

3) The enemies are stupid. They were never bright to start, but I realized that I could dash right through them. Then since I was behind them, they would forget they saw me and go right back to patrolling in the direction they were facing, namely, away from me. So I had an idea, which brings me to my next point.

- I decided I want an “On Alert” mode for the enemies. So after they have seen you, but no longer see you they will be on the lookout and will attack you if they see you either way. In effect, Alert mode would make the line of sight all the way across the screen all the time. It would also give me a good marker to do things in scripting. But most importantly, you will not be able to dash through them anymore, since they will still see you. Then, since you’re probably still close, they could drop kick the teeth out of your head. Ah, bliss.

-Also figured out how to do retard transparency. I’m sure “real” transparent items have some kind of cute “draw every other” effect or some crap, but I want my thing to not flicker and look bad. So, I plan to have the frames have a tiny single pixel checkerboard on them in the color of the mask (the color the system does not draw), and offset this by a single pixel in every frame. So, every frame will only show half, then next will show the other half and each time it will show what is behind the transparent item, so it will look clear. I could then adjust how transparent something is by changing the number of mask pixels in it.