It's NPC Time, Bitch

I realized I have no idea how to start to structure my NPC code. Well, I did have an idea, and I am having it critiqued on a forum, now. 112,000 files scanned.

Defrag

My computer has not been defragmented in a long time. So I cleared off a lot of stuff, and I am going to start a defrag right now. Later, people. A lot later, depending on how much stuff I need is on my hard drive.

EDIT: Okay, that took nowhere near as much time as I thought it would. It took longer to free up the space needed to defrag in the first place. And apparently my D drive needs no defrag. So, it being only nine at night, I am ready for the programming to continue. In four hours, you shall see me post, "So, it being only one in the morning, I am going to do some more programming." I am, I admit, somewhat obsessed. But, I have reason to be; I only have just over two weeks until college begins. A new semester, six classes, friends who live with me, not nearly as much free time.

Well, I only have one class on Monday and Friday, so there's time then.

EDIT TWO: Running a virus scan, and later a spyware scan. My Explorer.exe is, for some reason, randomly consuming 50-60 percent of my processing capabilities. I don't mind it so much, I suppose, except for the fact that I'm afraid it is degrading the performance of my Java compilations. More later.

EDIT THREE: ~60,000 files scanned, and nothing yet. Unfortunately, there are 300,000 to 400,000 files on my computer. Maybe a little less, since I just deleted a few programs, and games. Now I start on NPCs. Damn, this is tough.

First Look

Okay, so I got the idea to make a small video of how my program is doing so far. I guess all I'm gonna say is that this is just a test map. Two of the protrusions in the corners started life as NPCs in my old map, and that 3X3 block toward the lower left edge was once a small building. They will be again, but for now they are trees. Also, I want to say that all the images are sprites taken from various versions of Nintendo's Pokemon games. They own them, and I am not collecting any sort of fee for their use, so I am off the hook as far as legality goes. Enjoy... me walking around a map....



So, how was it? Was it cool? Did it make you all tingly with anticipation? Did you notice the background trees shifting unevenly?

Bah, never you mind that last part. It looks good enough in person, and better on video, I think.

I am suddenly exhausted, and my eyes hurt a little. Break time. I'll begin anew later.

Success, Success

I am very happy with myself. After looking online for a very long time, running through forums and websites and shit, I have determined that my game is pretty damned good. I also "fixed" it again. Remember all that crap I gave myself about making the character turn in place? Well, I ended up setting the direction, and then starting the move thread, and finally adding a slight pause to the thread. That pause gave the computer a chance to ascertain whether or not the key was still being held down. So very quick taps gave a turn in place reaction (just like the actual game). Well, I realized that this pause (30 milliseconds) was actually showing up in the game, giving my animation a very slightly noticeable hiccup every half second or so. You would have to be paying attention to spot it, but it was there, it was responsible for part of the perceived crappy animation, and it was getting on my nerves.

So what I did was change the location of the small pause. I made it only register if the direction was not set. So when the direction was set (like after you had finished turning in the direction, and either held the button, or went to tap it again), the pause no longer occurred. This led to some smoother animation, and a happier me.

I now have the player done (for the moment). I still need to shift more of the code to the player class, but that will come later. I'd say, as far as the entire game is done, I am now somewhere around 1/200 - 2/100 done. For those of you more idiotic than a fifth grader, that's 1/200 - 2/200. Not much. Some of it will be easier, though, so I am alright. Art and music will be death; I may have to find someone else to help me with them.

Later, peoples, I'ma gonna find something else to do (programming-wise).

Hey Justin.

New Ideas

So I stumbled across an interesting little tidbit, while roaming through Java forums. I now about an interesting little thing call a Rectangle. No, I'm not a moron. It's a programming thing that can help me know when stuff comes into view of my "camera" into the little world I have created. The Rectangle would be updated constantly to follow my character, and the rectangles of other things, like NPCs for instance, would set off an alarm when they intersect with it.

Unfortunately, while this is a good way to detect other characters, I do not see how it can be effectively used to make my tile map faster. Oh well. I heard Quadtrees are good for large maps, but I cannot find good documentation on them. I'll look around again, though.

Oh, That Was Easy

I did it. In record time, too, I might add. My character turns in place (mind you, you must tap the arrow key pretty damned quickly), and turns and walks without significant pause. Gonna work on some other stuff, now.

EDIT: Blah, did some more stuff. Tried experimenting with VolatileImages. I did not like it. It actually slowed everything down. I thought it was supposed to make images faster accessed? Whatever. Back to BufferedImages. There's a small amount of distortion in the images as they are drawn (something like tearing but not nearly as bad), but I think I'm cool with that.

So, I also checked out, once more, my emulator for the Gameboy Advance. I played some Pokemon Crystal (my absolute favorite version), and looked at how that looked. And I realized it was just as terrible as mine. That same sort-of-tearing is there too, even through the best filters. So that means my version of the game is just as good as the best emulated version out there. Awesome.

So, I have finished the basics with my character (just the walking, though), collision detection, the tiled map, all that sort of stuff. Next up is the NPCs. I am going to make two of them (like in the original test map), that walk around a predetermined path. I have no idea how I am going to do this, but I suppose it will be something like, look around the visible portion of the map (can be done while in the animation loop). If there is any portion of an NPC's path being animated, I shall set that NPC into motion. If their path is no longer animated, they go dormant.

But first, lunch, and Rush Hours.

Ah, Sleep

I obeyed myself, and went to sleep last night without programming anymore. I woke up fresh with no headache, and took a nice, warm shower. And then I got some breakfast and started programming. I have it now so that my character can turn in place, and I also have him moving smoothly across the board. The method I wrote down last night did work, although it took making a new thread in order to do so.

My only problem with it now is that the pause when turning in place is too long. In the actual game, if you quickly tap the directional pad, the character turns in place. However, if you press it down, the character turns and immediately starts walking. I replicated this in my original program (I looked at that code, tried to adapt it, and promptly trashed it, starting from scratch). But on my program, when you turn and walk, there is a pause (allowing you to otherwise turn in place), before the walking. The rest of my day shall probably be spent getting rid of that pause.

It is almost time for lunch, though, so I may give it a rest for a little while. I also wish to enjoy my copies of Rush Hour and Rush Hour 2 once more. I'll see what I can get done.

Later, peoples.

Why Do I Do This To Myself?

I started programming again. Why? Just because I did. I had a goal in mind. Did I reach that goal? Yes and no.

Well, I realize that there are some things I should have done, that I did not. Before, I had the code for making the character look like he's walking separate from the code to actually move him. This is trouble, because when the character is moving against a wall, his feet still move. In a perfect world, that is. This was accomplished in my old program. However, the code to do that is now dependent on the the arrow keys being effective, which, now, when I run into a barrier, they no longer are. This is a problem I must fix.

Also, I am experimenting with different ways to move the character continuously. I have tried several ways, but none seem to work to my liking. I am actually getting an idea right now, so bear with me while I write it down.

I use steps in the X and Y directions to mark movement. These are increased by 8's until the desired goal (+tileSize, -tileSize) is reached. This produces the smooth movement as the character walks. I am thinking of using the flag methods to flag the keys I am pressing down. I am thinking that I can program it to only acknowledge the held key when no other keys are pressed, and also the steps are only divisible by tileSize. That way, it will not continuously read the flagged key and zip my character across the board.

Tomorrow, though. Absolutely no more programming tonight.

Later, fucktards.

More Done

Phew, did a little more. I got my guy to walk. And I figured out how to use classes and junk. I have a class for my character now. Of course, there's some stuff I should do to optimize it, to ready it for possible changing resolutions, but I'll get around to that later.

Next up is something I completely forget how to do. I need to make it so that I can turn in place, rather than automatically walking in the new direction. Then, I need to make it so that I have smooth walking, without that little jerk at the beginning. Now, I know what some of you are saying. "Flag the keys being pressed, and you won't have that pause!" Well, fuck you all. That makes my game too fast. I had a way of doing it with just the keyPressed() code, and that's what I'm going with.

It's almost one in the morning, so I think I will finally call it in, and get ready for sleep. Tomorrow I will look at the old code I have for that, and find a way to implement it into the current programming.

Fixed Something I Didn't Even Know Was Broke

So, I started noticing this little thing where the character started out on a tree. It was fine to move, and of course I couldn't move back onto the tree. So I decided to change the starting position of the character. Unfortunately, I noticed that the playerPosX, and playerPosY numbers seemed to dictate where the character would come up on the screen, not in the field. Well, I fixed it. I had to add two variables, ones that measure the initial distance from the original starting point. This makes me realize I shall have to make a method that initializes all the character information when the game is resumed. I know I should have already thought of that, but hey, this is my first serious game, and I'm learning as I go.

So, now my character is centered on the screen no matter where on the board he starts. I was in the middle of getting the sprites for him up and working, so I shall continue that now.

Done

Collision detection is working. It was just a little switch statement using the direction, and whether the tile above, left, right, or below was a one or a zero. I only have two different tiles now. In the future, tiles that the character collides with will be within a predetermined range of numbers. That will be my collision checker.

Alright, Whatever

I ate some more food, and my headache is more or less at the same intensity it was earlier. So, I am going to go ahead and do a little programming. Gotta go up to my bed, and get comfortable first. I discovered that the power button on my tv remote, which I had believed not to be working, actually does. It's a little tricky, but it saves me a naked trip across the cold room, out of the cover of my warm blankets.

I'll have some results later, peoples. It's collision time!

Java, For You Peoples

So, I did a little search for Java in blogs, and didn't come up with anything useful. Then I was searching around Facebook for Java groups, and in one, I found a link to a blog made by someone who was writing a Java tutorial. In the interest of internet friendship, I am going to put a link here so that people can go check it out, if you want to learn Java. So far there are only two posts, two lessons, but if they stick with it, it looks like it could be good. So, enjoy this, and learn, people.

http://toastcode.blogspot.com/

If I see anything on the blog that looks wonky, I will point it out.

I Don't Heart New York

Scratch that, I fucking hate it. I love Philly much more. Why? Well, I respect assholes (this city being full of them, and I myself am one), I don't mind the filth, and frankly, the 400+ murder rate is something of a draw to me. I don't ever want to leave. I also hate traveling with my family. They hate taking me places, too, and have vowed never to do so again. On the plus side, I got to see my sister for the first time since I started college three or so months ago. That was alright.

I have a headache (which set in just before the Indian food, which was the reason I went in the first place. I had the mixed grill tandoori, which was still good, though a little burnt), although it is mostly gone. I am eating some food to help rid myself of it (I tend to not take medicine for stuff unless it's prescribed). But as for Java, no. No programming tonight. Just... no.

Tomorrow, peoples.

Yes

Well, your intrepid programmer has taken ten minutes out of his time, even when he said he was going to be leaving for New York, mind you, to do a little more programming.

I have moved the player to the center of the screen (I made it so that when the drawing section hits the tile that represents where my player is, it leaves the square blank). I have also fixed the screen so that it is centered around the player (it was not, before). Also, since my tiles are 96 pixels in size, they do not stretch completely down to the bottom of my 900 pixel screen. Therefore, there is a small strip at the bottom that shows part of the next couple feet down, and it does not update correctly. I have taken this and covered it with a black bar. In the future, I plan to move the entire screen to the center, and put two small black bars at the top and bottom for more of a widescreen experience.

So now I have a little gray square in the center of my screen. I suppose this can be used to make my collision code before I make the player code. It jumps when I move, because it is not a picture that moves smoothly, but it gets the job done. The player is going to be centered in the screen at all times, turning whichever way you're pointing him, and walking when you walk (runs when you run, fishes, etc.). So that will solve that glaring thing.

I leave in about forty five minutes. I do not think I shall endeavor to program any more until sometime after I get back. I gotta check my Facebook and stuff.

Tired

Well, it is roughly one hour before my little family sojourn to New York. I have been tinkering with my program for the better part of an hour now, and I have some good stuff to report.

I have fixed my camera (what I call the chunk of code that shows only the tiles around the player). Before, it went through every tile, and used an if() statement to determine if the tile was able to be shown. This was fine for my test grid of twenty by twenty. But, the actual maps are going to be a fair share larger than twenty squared. This game is going to be a free roam game, unlike the other linear Pokemon games. The grids are going to be very large. So I have changed my camera so that instead of running through the entire grid, it now targets only the area around the player. Actually, there's still one aspect I can't get my head around, but it works, so I think I'm alright.

Now, it gets a little buggy when I go out of bounds, but in the actual game, I will be doing what they did in the other Pokemon games: there will be a ring of trees around the borders of the map that will extend slightly beyond the screen. That way, when you hit the edge, there's no trouble caused by trying to index out of the known array.

Collision detection, that is next. Well, actually, I want to insert the player in there first, so that I know when I should be colliding with stuff. So, the player goes in, and then I start colliding with stuff.

But alas, first I must travel to a land just to the north of Pennsylvania. I must go to New York to visit my sister and eat Indian food (no, I'm not Indian, but they make damn fine food). Programming later. And in my head while I'm there.

Oy, the Equations

Thank god for Serebii.net. That site has absolutely everything I need to calculate shit out. It has the equations for stats, exp, and everything. So, I will say this. If, and only if (or as my MAT 101 teacher would say, iff), I can find sprites for all 493 (what a god awful number of Pokemon) Pokemon (front and back sprites), I will use all of them in the game. This adds quite some time to the development, but I get a feeling my game will be more popular for it.

New Approach, New Hope

Well, hello peoples of the internet. I'm sure I get, on average, zero readers per month, but that's alright. If anyone does read this, know that I have once again started this project, and I mean to see it through to the end, even if that does take a long time.

The last time I did anything with this game, I was using a windowed screen, and a large image as the background my character and the NPCs moved on. Well, this has changed. After two days of experimentation, I have created a tiled map system that works. It looked to have a lot of tearing, but that was because I was using blocks with hard edges and angles as my map. Well, I replaced them with threes and grass, and the tearing is gone. Well, not gone, but the human eye has trouble seeing it. You can still see the tearing, but you'd have to be looking pretty damn hard, and know what you're looking for.

Right now that is all I have- a tiled map that shows the area immediately around the player (or the center of the screen, actually), and moves smoothly just like the GameBoy games. Also, I have implemented a new structure of programming that I learned for a fantastic book all about game programming in Java.

So, I have a little day trip planned for tomorrow, and I am beat for today (been programming for several hours straight today and yesterday, plus a chopped onion is making keeping my eyes open somewhat painful), but on Wednesday, the programming keeps going. I am going to be putting the main character in at the center of the screen.

I need to fix my arrow key scrolling (a method of keeping it from going haywire is also keeping me from scrolling continuously), and then I start on the character. I need to resize my character images (there are many images). Then I need to import them and store them. After that I need to make it so that I can turn in place (I completely forget how I managed that little gem in my old code). Then I can start. I believe I can readily use a value that determines the movement of the map as the basis for determining when the character takes his steps. But gah, my eyes hurt, and my brain hurts. No more thinking about programming right now.

I still have a story to make. And i am still deciding whether or not I will include the newest Pokemon from the DS games. That will add a certain amount of difficulty. That would mean male and females of Pokemon (which I was planning to do), but also characteristic differences. Plus, I don't know if anybody has yet calculated the stuff like experience gains and stuff. I need that to be well documented if I am going to program it into my game. Whatever.

Food time. Later, peoples.

Thinking things through

Well, I just sat for a while on my bed, thinking about how things are going to be going down in the program. I don't think my old method will work. But, I have a new idea, one I know will work, although it may not give me quite the results I was looking for. I shall give it a try, however. It uses clips to clip a bit out of the overall image, and draw that to the screen. Then every time the player moves, the clip shifts to include the new portion of the image, and draw it to the screen.

I know for a fact that it was drawing the entire image area that was taxing the program. When I did something that caused the program to not draw the image, the character on the screen no longer flickered. It went back to flickering when the image was drawn on the screen once more. So now my objective is to make things work correctly.

I also have many other objectives with this recode. They all include making the game run and look better, of course.

Now I am trying to think of how I shall handle things with the different maps. to counter one issue, I think I might make the array three dimensional. The second Z layer would include the path values for the NPCs. I don't know if one 3d array is better than two 2d arrays, but I think it might be.

I plan on getting food soon, so programming later. I downloaded the beta of Netbeans 6. I'll do all of my work on there from now on. See ya later.

New stuff

Alright, I have looked intently through my new Java book, and have come up with some new stuff to try to implement. The code is going to be rewritten from scratch, hopefully a little more smoothly than it was last time (an impressive feat, since the last recode went so much better than I ever could have hoped for).

In this recode, I am going to try to take some of the strain off of the GUI aspect of the program. Remember from last time, when I said my last attempt to take the pressure off the GUI was unsuccessful? Well, I think I found at least one of the ares where I messed up, and I know how to fix it in part. The rest I'll fix on the fly.

So, the things that I will cover: I am going to make it so that only the image visible in the screen is drawn. I am also going to do away with the collision array maps. This time, the collisions will get their values from an actual map feature, in which one set of variables of type A can be paired up with a variable from type B. This means that an Image file (the sprite) can be paired with a boolean, dictating whether or not I can walk across.

I think what will end up happening is that I will have two sprite two dimensional arrays for the entire board. One will include the background sprites, like the ground, and what type of terrain is there. The other will lay out things like buildings, and rocks, and people. This will be the array checked by the map.

Unfortunately, as I type, things are falling apart in my head. I cannot quite figure out how some things are going to work. Dammit, I'll just start coding right now, and hopefully, I will be able to figure them out on the fly. Later, people.