Hey there, and welcome to the Lufia (Unnamed Project) Development blog! I’ll try to post as often as I can with the progress of the game I am developping, and how my ordeals are paying off. Bear with me in my time of hardship, for I have a lot to learn! 
Before I made the step from offline to online reporting, I have kept record of my progress since the beginning of july. To get started, I’ll post those entries here as one big ‘update’, if you will, to give an indication of the challenges I’m facing, and how fast or slow game development can be for one individual working in his spare time
21-07-09
********
Did some minimal changes in the code; I learned about static_cast<> only today, and put it to good use. Arrows are now actually fired using Shoot(Direction), rather than Start(Direction), and the jar is now Lift() or PutDown(), rather than Start(0) and Start(1). A major improvement, I’d say
I want to finally start on a way to read and execute scripts. I’m not quite sure whether to use Python or Lua, but one thing is beginning to become more and more clear- Dev-C++ won’t cut it anymore. It hasn’t been updated in years, it’s a pain to find support for it, and any additional libraries I wish to use are an absolute hell to compile. As everyone seems to be down with MSVC, I fear I’ll have no choice. I’ll begin working on the transition (which won’t be easy, which is what kept me from it in the first place, among other reasons) today. Wish me luck…
20-07-09
********
Screw switches, hehe. I’ve created little animations when lifting the items, rather than just making it go POOF over Maxim’s head. I also created a new class for the crate, and it can now be blown up using bombs, creating smoke where the crate was before. Also fixed a bug where, if you were fast, you could simultaneously move and place the item on the ground, meaning you could walk through it from that point onwards. Think I’m calling it a day
19-07-09
********
Just implemented three liftable items; the jar, the crate, and the grating. Solid under normal conditions, but you can lift them, and they won’t hinder your movement anymore. The items remain over your head until you put them down, and that cannot happen if something solid is already there, or if there’s a wall. I just remembered that it would be handy to limit maxim’s skills when he’s carrying something, so brb 
[...] Done, hehe. Now on to switches!
18-07-09
********
Worked some more on the text engine (hey, you know me by now! 
– it will now correctly show the balloon arrow behind the character, if it’s talking to someone, and text can now be positioned south of the character if it’s talking to someone north of him. Since I rather liked the fact that I could have people talk while walking, I also tweaked a bit, so that these new changes work even when the character is on the move, and changing direction. Getting tired though (several reasons, among which the fact that I burned my hand badly at work today), so calling it a day already. Fare thee well Lufia!
16-07-09
********
Didn’t have a chance to do anything yesterday, what with the work needed to be done in my sister’s home, but I continued on the text engine today. Characters will now appear one by one, will fade in, can be shaken (fun effect if people are frightened) by the first attempt at in-message parsing. At this point in time, the “\s” will toggle shaking text on, and using it again will toggle it off. Be reminded of the fact taht, in order to put it in a string in a programming language, you’ll have to use “\\s”! In the future, I’d prefer it like this; “Oh no, what’s \b{THAT!?!}”, but hey…
UPDATE: past 1:00 AM now, guess it’s bedtime. Anyways, making text shake is now possible with \s{TEXT}, changing text color can be done with \c{R,G,B}{TEXT} with RGB being values between 0 and 255, 6 different border types can be used at will, and delays using \d{n}, with n being the amount of frames of extra delay. Hoo yah!
14-07-09
********
Improved on the framerate independant movement. It now directly takes the rendering time of a single frame, rather than the fps, to determine how much instances should be moved. Dialogues are still glitching a bit when the framerate drops, but I have no idea yet where that is coming from.
Implemented the speech arrows on the bubbles, both left and right, and fixed the allignment of the bubbles. Now for the following:
* gradual text appearance
* Color altering (don’t forget to make the default color into the light grey, rather than white)
* delays
* pauses
* fading?
* different border styles (think bubble, royal, etc).
* writing the border to its own temporary texture, for optimization
13-07-09
********
Got basic dialogue working, but I’m not satisfied, on several levels. It slows my game down like a madman, because I redraw every single 8×8 part of the frame on each iteration. The best sollution would be to draw the frame to a texture ONCE upon creation, and simply use that texture while the dialogue is active. However, that proved to be trickier than I thought, so postponing that for now. Would be nice to have though, the map could benefit from it as well. Why redraw every tile on screen each iteration, when it’s much faster to draw one big texture?
The slowdown gave me a good excuse to finally start thinking about framerate independant movement. It annoys me beyond measure that, when my framerate drops, the entire game starts to slow down- Maxim walks slower, my animations are therefore no longer correct, etc. Working on that for now, might take me a while. A GameFAQs user suggested to multiply the velocity of moving objects by a factor, depending on the framerate as opposed to the desired rate. Sounds good to me, but opposes my previous mind****s (that led to nowhere, mind you) of skipping frames, but keeping the game logic at 60 iterations per second. No matter how I looked at it, I couldn’t quite grasp the idea on how to solve that. This method I _can_ do, so will see where it leads
[...]
Seems to work, to some extent. My dialogue is now stuttering though, so cannot be used for moving characters. Needs a lot of revision.
12-07-09
********
Took a break, due to work, but currently working on the dialogue system. Decided not to implement this into the object/instance system, but create a new one designated to the dialogue. Needs a lot of work still, but I got the text to show, as well as define where the borders of the box should be. Press T to show the various test messages.
08-07-09
********
Had to revise the map boundary checking for it (again, I know), but arrows will now deflect from map boundaries as they should. It was well worth the effort though, because I can now detect passing boundaries regardless of speed, so even when an object has a speed so great that it would have simply ‘skipped’ a wall. Those collisions are detected now as well, for both the player and the arrows. This in its turn means that i am no longer bound to speeds that are multiples of 2, meaning things will animate a lot smoother now.
Arrows are now functional, will be put against the wall they bounce with, and will create a small animation of a bouncing arrow when they impact. For now this will do, but eventually I also want it to be able to stick to certain instances, such as enemies. Not now though, I’m eager to jump to speech bubbles- a big challenge, considering my demands Also made Maxim change his pose temporarily when firing an arrow, changing back to normal after 1/4th of a second. I must say, implementing this last change was a piece of cake now, despite the fact that I had to use a timer and a different sprite- I conclude from this that my design is getting along, as this would have been a major thing to edit back when I just started on the project!
06-07-09
********
Been working on the arrow skill. One’d think they’re rather easy to implement, but the collision detection is throwing me off. At the moment, the arrow simply keeps on going until it hits something, and works reasonably well. The fun comes with the map boundary checking, and later collision with other elements, among which switches and enemies.
05-07-09
********
Implemented function to check the amount of and type of instances at a certain position. Creating bombs at a tile where a bomb is already created is no longer possible, and this makes combining puzzle elements possible. Bombs can destroye achother, next step is to implement timers to create a nicer chain explosion.
NPC collision working, more or less. Only topleft coordinate of target position is checked- if there’s an NPC there, the player won’t be able to move there.
