[DanKirby]

Took me forever to figure that out.

Anyway, I have the scripts all set up. For outside of battle, at least.

I'm going to try to build up the town before attempting to design the battle system. I really haven't given the battle system much thought beyond the basic concepts. I'll probably use something similar to what I had in ToL, only a bit more advanced. There'll be a lot of new scripts involved with it, I know that.

[Joakim]

[skip this]
I have always prefered my own scripting languages for my own games. This is probably because I am more of an engine and environment designer than a game designer, and I want to make engines or games that can be used for more than just my own current game idea (which I know I will abandon within a week anyway). All generic languages like lua, gamemonkey and javascript bugged me because they lacked features I'd like to exploit or had syntax issues I didn't like. Over the past years I have made numerous half finished generic scripting languages in attempt to create a language with the exact features and syntax that I wanted. None of the serious attempts have reached compleation, although many reached a fully working virtal machine and compiler except from lack of a couple of features (think arrays, optional arguments, engine api function calling).

Until a week ago. I am currently developping a rpg engine with an integrated development environment (read: advanced editor w/ map editing, object editing, script editing, etc.) with Ninkazu that relies heavily on the scripting lanugage. My main task is this scripting language, and I had an almost complete VM and a half finished compiler before I realized that a generic scripting language is not the way to go!

[you can stop skipping now]

I have reached the conclusion an engine deserves a scripting language tailored to the engine it controlls. Superfluous features adds unnecessary syntax complexity to a language that makes the learning curve steeper and slows down all coding that needs to be done in the scripting lanugae. Besides, these unused features will most likely take up a good chunck of your memory and your precious clock cycles by making the virtual machine more complex than it needs to be for your purpose.

There is a reason why commercial engines have their own scripting language that contains all the features you need as a scripter and nothing more. UnrealScript is a good example; look at it's engine specific states, it's replication syntax and it's latent functions. This concept makes it possible to quickly perform repeatitive tasks in an easy to maintain manner.

It is of course a lot of work to create a solid scripting language, but I'd say it's worth it in the long run. If you chose to do it, I'd advice you to make sure you chose a syntax that you are comfortable with and have an at least somewhat wide appeal, or you will end up rewriting it soon. Also plan you scripting language and engine on the same time, so you can figure out exactly what the scripting language needs to be able to controll in the engine (and how), and exactly where the engine needs to call scripts or functions within scripts. Engine to script and script to engine communication is incredibly important aspects that you need to sort out early in development. Finally, I'll dare to claim that if your script to engine communication is limited to calling engine api functions from the script, it's probably too generic.

My $ 0.02

[DanKirby]

It's been a while, but there's not much updating to do.

All I've done at this point is make one house, and fix a few bugs in the engine. And the house is way too big. I'll try to make the rest of them a little smaller.

I've been playing around with Modplug trying to make some music for the game, but it doesn't sound very good. Anyway, I've gotten off track (no pun intended) by doing that, but hopefully I'll get back to the game soon.

Music can wait, I need to finish this town. Then, it's on to the battle engine (ugh).

[DanKirby]

I tried SDL_mixer in the engine for music playback.
Appears that it doesn't support the "Position Jump" command in my MOD files, though. It appears to treat it like a pattern break, and loops the whole song.

Anyone know of another library that handles position jumps normally?

(edit)
I tried out FMOD and it plays my files correctly. So I think I'm set for now.

[DanKirby]

Put up a few screenshots of the game on my project page. I didn't really do much with the tiles...tried to break up the grass tile a little, put a little more texture on the siding, but I didn't do a great job.

I really need a better textbox...right now it's just a plain black rectangle in the screenshot. But I can work on coloring or texturing or whatever I'm going to do with it later.
What I think I'm going to do for now is put a colored rectangle inside of a white rectangle so it at least has a border.

I've made four buildings so far. Need to work on the houses next.

[janus]

[DanKirby]

Progress update: I think I've made enough houses for now. I'll add to their scripts later.

Right now I'm facing the task of extending the characters' sprite sets to include new animations... Attack, technique, and victory animations, among others. It's turning out to be a large task, as I have to come up with animations for every character that can be used, including the regular townspeople. I'd probably make very simple animations for those minor characters.

Anyway, after that, I have to make the sprite sets for the enemies, then the tileset for the forest before I add the last big parts of the engine: the savegame system and the battle system.

I should really make a website for this project's progress log.

[DanKirby]

Decided to put the sprites aside for now to work on the save-file system. The files are actually saved, but I can't reload them.

The problem is that the data isn't put into the files with a consistent size. A number 3 goes in as "3", 50 goes in as "50", and so on. This is a problem when the data stored could be any number of digits.
Back in my QB days, binary files always saved ints as 2 bytes, long ints as 4 bytes, and so on. I'll have to look into File I/O more later...I think I'm using the wrong functions.

I'll get it right eventually.

[LeoDraco]

[DanKirby]

Yeah, that was it. I changed everything to read() and write() and it's all working now. Back to the sprites now, I guess.

(edit)
Come to think of it, I actually used that tutorial when I was first starting out in C++. It's just been so long since I actually needed to use the I/O functions that I completely forgot.

[DanKirby]

Ugh...making sprite animations is hard. Especially when you're not very good at it. I'm only about halfway done with the first character. Then I have to make animations for 6 others, and that's not even getting into the enemies.

I could just make the main 3 for now (or even just the one I'm working on), and then code the battle engine, and test it with clones of them fighting. Heck, I'm getting tempted to just try making the battle engine right now, with no animations. Then I'd get back to the rest later.

Finishing the demo might take longer than I thought.

[PhyrFox]

It's often useful to draw the sprites on paper or somewhere, so you can place them side by side, or "flip" them to test the animation. When you have what you want, it's then just a matter of digitizing them. Maybe a digital camera, and then, of course, reduce the resolution and cropping and such. Or just draw them by mouse. Either way, it's useful to have the animation frames side by side, where you can see the comparison between frames. I personally have the previous frame, then a copied version of that frame next to it, then modify the copy, so I know more precisely how to adjust it.

Just some bland tips....

~= PhyrFox =~

[DanKirby]

What I've been doing is just drawing the poses in stick-figure form on paper to see how they work, then I draw the sprite on the computer using that pose.

Anyway, I almost have the first one done. I won't be able to work on the computer this weekend, so I'll basically be refining the details of the battle engine in writing. When I get back, I'll start work on the engine and test it with that one sprite before drawing the rest of them.

[DanKirby]

Coding the battle engine now. This is probably one of the most complicated parts of the whole program. I'll bet it's going to be a real pain to test.

Right now I'm working on the data initialization and the menu controls, and then I can start a first round of testing.
Pretty much all of the battle mechanics are handled by scripts, such as moving and animating the characters, calculating damage, and such. The functions to work with scripts will be added after the testing of the other stuff.

Of course, even after all of that is finished and tested, I'll need more testing once I have the rest of the sprites and the actual enemies and stuff.

[Hajo]

Wow, this really goes on a tremendous pace!