I’m here just to quickly point you out to our new WordPress blog URL at sonettoproject.com.

We’re not going to update this blog anymore.
See you at our new place!

It seems almost ridiculous to me how easy society (familial nucleus included) can make giving up on dreams be. That is, from the bottom of my heart I don’t feel like giving up on this project, but, heck, if I didn’t have an absurd desire towards its completion this would have been a lost match. All wrong, this is all wrong…

But I shall create those games I so want no matter what. I have already almost given up when we started developing Sonetto, and today it is with unprecedented pleasure that I understand that I would have had only myself to blame if I had given up that time. This project has got almost nothing on itself, but it’s already a VICTORY for me to have stood by its side for all this time, so it can’t be any different that there will be many more “wins” to come when the project actually start to take form.

Lastly, a quick update on the project’s code base status:

• We are using Git as revision control system for our repository. I always disliked those .svn folders everywhere which would break things so reliably when moved around. I also like the possibility of making local commits that may be dropped or regrouped before being pushed to the repos, something that wasn’t possible with Subversion.
• We have adopted Boost libraries (http://www.boost.org/) as a new dependency for Sonetto. Those guys are beasts at solving programming problems.
• Linear algebra library Eigen (http://eigen.tuxfamily.org/) was also adopted; it’s also bestially useful.
• We have dumped Ogre3D (it was a fine engine to learn from and may even be fine for some commercial projects, but it doesn’t fit our style in many ways, so it’s bye-bye) and we will only support Direct3D for now. I still hate all APIs by Microsoft I have ever seen, but nothing could ever be worst than OpenGL’s API. Microsoft wins until a new alternative comes by.
• We have changed our terminology a bit, also. There aren’t Managers anymore, but Systems. Systems can be either Core Systems or normal Systems. Core Systems are those which share state among game Modules, so their lifespans have to be the same as Sonetto Core’s Kernel. Normal Systems, however, have their lifespan tied to the Modules that instantiate them. An example of a normal System would be the Walkmesh System: it doesn’t have to cope with the existance of many Modules, although it’s used by many of them.
• The Input Core System is done writing, but 2/3 of it were not even tested yet (those two parts correspond to the DirectInput and XInput portions of the System; I’m lacking of controllers right now :] keyboard support works, though). Oh, and I didn’t code the force feedback part of it, also, but, seriously, this is dead easy..
• Resource Management is gonna be handled by a separate library of the project. This library is still urging for a little bit of rethought, though, and not a single line of it has been transcribed to C++ code yet.

Dunno when I’ll post here again. In fact, I’m only posting this because I like to write stuff from time to time. Oh, boy..

Regardless of that, though, Marco is on vacation now, so he can work in Sonetto Project freely ’till March. Yoasakura is trying hard to overcome his difficulties of drawing amidst the “chaos” of his own house, and I am working on Sonetto Engine in a private repository (we are working on commercial projects from now on; we will only cleanse Sonetto from commercial code and release it as open-source later on, for personal reasons). We may or may not post some screenshots when we find it appropriate.

So, that’s how it is. Not half as shiny as we expected.

Regarding the BRGames contest, as long as its specifications are not released, we would say we are still trying (well.. not me, but Yoasakura, Marco, the “major” guy beyond the story of our game, although everybody work on it a little bit , and Cimirro, the musician).

It will be a somewhat tough time for the project, but it must be clear that nobody is thinking of giving up here. 2010, on the other hand, will probably be a very good year: I will not be on school anymore, the situation will be much better with Yoasakura finantially-wise and I’m sure he will have his drawing skills much improved by then. My studies start tomorrow. I wanted to put GenericMapModule to work before that, but seems like it won’t. Anyway, that’s it. I’m heading back to my city now (was out on vacation). See you next year .

And not to waste this post without any news, Sonetto still doesn’t have the MapModule it had before we started rewriting it, but I’d dare saying it works much better than before (just as usual after a rewrite). We are not rewriting it anymore, but actually “adapting” the old code to the new decisions we’ve had. Yesterday I was hooking the InputManager to the ScriptManager. ScriptManager scripts now have access to input. Today I intend to do the same thing with the AudioManager and the Kernel (so that scripts can begin battles, for example), and then I’ll start implementing the MapModule and writing the Event-to-Event collision our WalkmeshManager lacks.

To an eventual brazilian interested in the contest, look it here [pt-Br].

And more importantly, Sonetto is being fully rewritten. This time we will concentrate on creating a functional game engine instead of one that’s so flexible that becomes a general purpose engine, and not a J-RPG one anymore. We will still use the module system, but the interface between those modules won’t be so abstract as it was before, thus allowing the modules to be “aware” of each other, creating a more tightly integrated system. In the way Sonetto will be developed, the freedom you have to easily personalize your game ends in the modules. For the rest of the engine, it will be needed to modify the Sonetto Core source code, and that’s exactly why we changed from LGPL to New BSD. We want you (and us, of course), to be able to create highly personalized games without needing to release the source code. LGPL didn’t permit it, but New BSD thankfully does. You still can’t statically link to Sonetto Core, however, as it itself is statically linked to other LGPL’ed libraries, unless you release your project objects (compiled .cpp files, generally named with a .o extension), so that other people can relink Sonetto with other or modified versions of the LGPL’ed libraries used by Sonetto at their will.

Yoasakura’s personal rant:
People often think that J-RPGs are all the same, but each game have their own peculiarities. They may be similar, but they are not identical–each game needs its own personality, being it a different battle system, or a different menu behavior. (You see, even games from the same franchise, even sequels are not exactly identical.)

I’m posting this just to say that I have implemented the sound sources thing that was lacking on the last update (about their positioning). Also, the WalkmeshManager is working just fine, althought its Event-to-Event collision test doesn’t work correctly yet. Still, the WalkmeshManager needs to be rewritten because its code is currently a mess. But what matters is that it is working now, and, most importantly, that we’re much more near to the fun part of the engine (yup, that means screenshots.. and maybe videos). Just wait and you will see

I’ve also uploaded some modifications Yoasakura did. He have created a “Slow Motion” debugging feature that can falsely decrease the game FPS and make everything run slower or faster than normal. It’s got to be useful! Yoasakura have also created a new concept for the Sonetto core: that of Module Factories. It standarizes more the modules, making Sonetto a more “focused” engine. It is a bit restrictive in a way, but much more expansible in another point of view (that of RPGs). I won’t go into details here because my time is short. I hope to post more news soon!

Unfortunately we have nothing new to show. We’ve been stuck trying to find out a way to make the player collide and slide with the world, and there are really few resources about this. Collision is so common in games, but still it’s complicated and there are no resources around to help, Most of Collision Detection Libraries today are focused on physics, and it seems that most of the indies around use physics to move their characters rather than directly by coding into their own engines. I don’t want to move the Sonetto characters using a physics lib, so the only way is to do it manually, and it’s pretty hard.

But we’ll figure out a way, it doesn’t matter how long it takes.