Tag: Progress

How Far You’ve Come

Dennis February 27, 2011 No Comments

Yesterday, I spent some time helping my brother on a development project he had for school. It’s going well, but it’s going slowly and it reminded me a little bit of how I started out. I didn’t have anyone to teach me PHP, MySQL or HTML or Javascript and I got into the CSS game very late. I had to kind of figure things out on my own, based on tutorials and examples I could find online. I remember well that I couldn’t figure out how to grab some info from a database and present it on a screen until Paolo Marcucci, a.k.a. ThatPaolo, sent me a little snippet of code. I guess it all started with that one little snippet he sent me over IRC.

My brother has me to ask questions to, to give him examples, to teach him some best practices, and even though I’m a horrible teacher, with little patience and a bad eye for sensing whether or not he actually gets what I’m telling him or whether I should change my approach or wording, it’s already going way faster with him than it did with me in those first few months. It makes me wonder; how much time have I logged trying to figure all this stuff out? And was it worth it? I’ve had tremendous fun and satisfaction doing it, but I could also have gotten my master’s degree with all the time I spent figuring this out.

I also went back into some of my old code — I actually put a very old game I coded, which I dubbed GridRunner, but which isn’t anything more than a simple game of kamertje verhuren, back online — and most of that was pretty terrible and inefficient. I remember GridRunner failed because I didn’t know what an index on a table was, so after a few games got started, the speed of those games dropped to abysmal lows as the database ground to a halt. (Indexes have still not been applied at the time of writing, so if you’re going to follow that link, know that it might still be slow.)

To top it all off, I went through years of photos that I’ve collected over time. I looked ridiculous five years ago. So skinny, less fat as well as muscle tissue. How far I’ve come. In a nostalgic way I wish I could go back and make some different choices, but that would mean I’d also have to go through the pain of some of the things that happened that weren’t the consequences of some bad decisions I’ve made, like my parents dying, etc.

Some people say they don’t have any regrets. I think that’s nonsense. Sure, you make the best decisions with the information you’ve got at the time, but decisions are like code; if you can’t revisit your code, or your decisions, in six months and can’t improve it, it means you haven’t learnt anything in that time.

Regret just shows you how far you’ve come.

Measured, Focused Progress

Dennis January 15, 2011 No Comments

One of the hardest things to with a two-man project that has the scope that Corrosion has is keep the momentum going. It’s easy to get side-tracked with items that aren’t the core of the problem you’re trying to solve. For instance, Robin and I have settled on what the end-game goals are going to be and there are a lot of things to be done before we implement it. crews, PvP, lifestyles, magic in combat, adepts powers, the list goes on and on. They’re all linked, so it’s hard to set priorities and when you’ve set priorities, it’s hard not to get side-tracked by frivolities.

One of the problems we had with the missions map was that certain tiles, those bigger than 32×32 pixels, were sticking out at the right and bottom edge of the map, and that some of those same tiles weren’t showing up properly at the left and top edge of the map. This because we were showing the tiles at 32 pixel increments in each direction, so if a tile was bigger than that, it would either not show up if it wasn’t showed in full, or it would stick out of the edge of the map if we weren’t going to show it completely. It always bugged me and a fix I contemplated for a long time was to cut all the tiles down to 32×32 tiles, and mixing and matching the tiles that were supposed to go together. It was going to be a painstaking and time consuming task so I wasn’t looking forward to it. And the only thing I’d fix were some visual glitches, nothing major and nothing at the core of the mechanics.

Then I realised another way to fix the bug and one that I thought wasn’t going to take quite so much time; I was going to hide the overflow of the <div> the map was set in, that would easily solve the tiles sticking out at the right and bottom end of the map. The only thing to figure out was how to make the not fully visible tiles at the top and left side of the map to show up. I figured I was showing 10 tiles on either side of the player, I might as well show a couple of tiles more on the left and top of the player, hide the overflow and that would be that. It worked, hurrah!

But that’s where things got off the rails a bit. That’s where it turned murky and what I thought was going to be a quick fix turned out to be a rather complicated problem to solve. Fortunately, it was going to be a problem I would have to fix sooner or later, so I guess it might as well be sooner.

It turned out, the tooltips I was using to display the information and attack sheets for the enemies and the action sheet for the player, was being contained in the same <div> as the map, which meant that the overflow of those elements would also be hidden. Considering how the tooltips often transcended the boundaries of the map, most of them (if not all of them) got clipped to the point of being useless. I wasn’t too happy with the tooltips to begin with, and I had found a different tooltip type that I had already partially implemented in different areas of the game that I had wanted to use but didn’t really know how to implement in the fluid, AJAX environment of the missions yet. But I wasn’t going to have to do that since I got the ball rolling on the overflow problems with larger tiles.

The other tooltips worked with a javascript mechanism that would go through the HTML after the “document.ready” event and filter out all the designated tooltip-divs, attach them to the top laying <body> element (which means they were no longer contained by the mission map <div> and would no longer be subject to the overflow clipping) and got tied to the mouseover, mousedown and mousemove events of the <div> they were nested in. Pretty nifty piece of work. I was quite happy with it. Until I realised that while moving, attacking, dropping stealth or any of the other actions you could take while on a mission, it seemed the tooltips would vanish. I spent an evening hacking around in javascript in order to solve that, but it would still ocassionally happen that the tooltips wouldn’t reload properly when an AJAX call would come back. It seemed to be tied with the glitch I had noticed for a while that the combat log didn’t always refresh like it should.

Last night, it seemed like I had a good idea on why the combat log wasn’t refreshing like it should. It seems some AJAX calls aren’t handled properly because of browser-caching, and a quick fix was to add a random GET key to the URL in question, making the URL that was called unique, circumventing the caching without too much hassle. (Sure, I realise that a javascript, “randomly” generated 8-character string is anything but random and will probably result in a 1 in 10000 chance that it will happen again, but give me a break!) I haven’t done any extensive testing, but the first signs are optimistic. Let’s hope it lasts.

And so, I come to the point of this big rant; it’s easy to get side-tracked, and it’s easy to let yourself be side-tracked. Self-regulating and self-motivating is the hardest part of keeping a project like this going, I suppose. Robin and I are intelligent enough to tackle most problems and if we can’t we’ll find a creative way around it, but keeping on the right track and not meandering off course is the hardest part. It’s hard to prevent, it’s hard to detect, and it’s even harder to correct once you detect it. Everything is important — no, everything seems important.

Pathfinding, A*, Motivation and Progress

Dennis March 19, 2010 No Comments

As you might have concluded from my last journal post, I got demotivated when I hit a snag in my self-devised pathfinding algorithm based on the A* principle of pathfinding. I knew that A* was going to be a simple, straight-forward and decidedly stupid way of finding a path, but I wanted to understand the principles of it before I migrated on to adding “costs” to the logic of the algorithm and making it smarter. I was shocked to see that with the relatively simple map that we had created, roughly 34×58 tiles large, finding a single target from one side of the map to the other made PHP run out of its allotted memory. And so, it took a few days for me to pick up the deving and figure out what was going wrong.

It turns out that when I started to examine the path that was returned for a relatively short example, that there were some mistakes. It returned some tiles as part of the path that weren’t supposed to be. Then I took a look at the examined tiles and there were way more than I thought there should have been. It turned out the algorithm wasn’t ignoring blocking tiles as it should be. When I had found the problem and fixed it, I found the load was cut by more than 50%. That was good, but it’s not good enough. I’m going to examine it some more soon, but it means there is still progress to be made before I start implementing the costs structure. Perhaps when I’m no longer able to streamline things, I’ll show you guys what I came up with.

Anyway, reinvigorated motivation FTW.