Progress and Relocation

(This blog is now closed. See the link at the bottom of this post.)

Ok, essentially all the core changes have been completed for the Summer release. This includes

• A completely new scripting engine, with much better performance and several new features
• An update to a newer version of Cube 2, with stuff like ragdoll physics (not all of which is yet enabled),
  
• Much rewriting in order to integrate with the new central infrastructure
• Writing said new central infrastructure (user management, asset hosting, metadata, etc.)

Depending on how things go with bugfixing, alpha testing (a closed alpha should begin in a few weeks), and artwork integration, the public release may actually occur slightly earlier than planned. That is, before Summer 2009 or early in it.

As part of the preparation for that, I'm moving to a new blog, over here. The new blog is called 'Syntensity', which is the name of the entire platform, whereas 'Intensity Engine' will continue to be the name of the core client+server package. In other words, the Intensity Engine is the code at the base of Syntensity, while Syntensity adds central server infrastructure, etc., in order to provide an actual running 'world' and services related to it.

Just to clarify, the Intensity Engine will remain open source, as always intended, and also Syntensity will be free to participate in. There is no change in direction here.

So, this blog will probably not be used any more, syntensity.blogspot.com is where updates about the Intensity Engine will occur.

Low Profile Until Summer

It's been a while since I posted. The reason is that several important processes were unfolding during that time, that I wanted to see play out before writing anything here.

First, I've been in talks with another open source virtual worlds platform, realXtend. In the spirit of open source unity, I suggested that we work together, but in the end they declined. The main reasons are that (1) they are invested and committed to using OpenSim, and (2) prefer to write a client from scratch, whereas the Intensity Engine (1) purposefully avoids using OpenSim, while at the same time (2) reuses existing open source code (Cube 2, etc.) instead of starting from scratch. So, while we have similar overall goals - open source platform, interoperable worlds, etc. - our technical decisions about how to get there are quite different.

Second, I've been considering how to achieve my goals with the Intensity Engine. Those goals are quite simple: To continue developing the platform, and to make that platform freely usable by everyone. So far I've been working full-time at my own expense, which is fine - it's a nice change of pace after finishing my doctorate last year. But although I can afford to do so for a while, that can't last forever. So, for the long term something needs to change. I see two main options here:

• Non-Profit: Getting some minor source of funding, basically just enough to pay my personal expenses, which are quite humble. Such funding might be in the form of a sponsorship, donations, etc. If such an option materializes, it would be great, and I'd be happy to release the Intensity Engine under a BSD-like license. In many ways this is my preferred route.
• For-Profit: Alternatively, I can try to make the Intensity Engine self-sustaining while keeping it open source. The most straightforward way to do that is the proven dual-licensing model, like that used by MySQL, Qt, Ogre 3D, Java, etc. - the code is free under an open source license, with the additional option to pay for a commercial license that doesn't have the requirements of the open source one. In this route the Intensity Engine's license would probably be the AGPL, GPL or LGPL.
  

I'm keeping an eye open for ways to make the non-profit option work (I'd love to hear about ideas for that), but I more clearly see how to succeed as a for-profit. Consequently, I'm in the process of forming a venture with some friends, called Syntensity. Syntensity is off to a very good start, in particular we have been picked as a Mini-Seedcamp finalist.

So, those are the recent developments. Following them, the Intensity Engine's roadmap and status are as follows:

• The Intensity Engine will remain open source and cross-platform. These are principles that will not be compromised. Likewise unchanged are the goals of the Intensity Engine: Making the development of efficient, responsive virtual worlds as easy as possible.
• Development of the Intensity Engine is continuing, at an even faster pace. The reason you have not seen commits to /trunk is that I am working on 2-3 crucial features in separate branches. Those branches are currently not public, because I prefer to come out with these features all at once with a single large announcement, rather than one by one. This 'stealth mode' is expected to continue only for a few months.
• The specifics of these crucial features will remain undisclosed for now. To my knowledge they are not present in any other product in the field, and I believe that with them the Intensity Engine will really come into its own.
  
• 0.9 beta release in a few months, that is, probably early summer 2009, which will include the features mentioned above as well as polish. After the release of the 0.9 beta we will focus only on further polish and bugfixing, until:
  
• Stable 1.0 release a few months after that, that is, probably mid-to-late summer 2009.

So, the past few weeks have been exciting and eventful, despite a lack of blog postings to reflect that. This relative blog silence will continue for a few more months, after which you will be seeing a lot of interesting stuff in this space.

Note to current developers: Be aware that API changes will occur with the 0.9 release. Consequently, applications developed using the 0.2 release or 0.3 /trunk will need to be modified in order to run on 0.9/1.0. Those changes are unavoidable in order to take the Intensity Engine to the next level. Note, though, that the 'spirit' of Intensity Engine development is not meant to significantly change, so experience developing with the 0.2/0.3 versions will be very useful with the 0.9/1.0 releases.

Various UnBlogged Updates

I've been too busy to write about recent developments. Here is a summary of events since my last post:

• TideTurner is progressing, visually and gameplay-wise. It now has sound effects, visual effects for damage and spells, a nicer map, and so forth. I hope soon to have it in a nice enough state to set up a server and invite people to connect and play.
• A smart asset management system has been written. This is a highly-modular system that can ensure you currently have the most recent versions of assets, i.e., you have the same maps, textures, etc., as the server. It handles checking the state of assets and acquiring them. Currently the system is in place for maps, which are both large and likely to change fast, so this was important before setting up a server for people to connect to.
  
• The network protocol has been significantly slimmed down: Smaller messages are sent for updating StateVariables, playing sounds, and so forth. Again, this was important to be done before setting up a server.
• Various code refactorings, which led to both shorter and more manageable code, in particular in the core LogicEntity system.
• Partial work towards smarter CPU utilization by the physics system: Fewer frames of physics are done for entities that you can't see well, and various physics frame rate parameters are now configurable. The overall result is a significant savings in CPU utilization, on both server and client. However, as I wrote this is 'partial' at this point, in some cases you might notice jerky motion due to not enough physics frames being calculated. The solution will be to carefully fine-tune the physics parameters, which is a complex matter.
  (Note to testers: You can disable the 'smart physics', which will revert to how Sauerbraten does physics - full speed, all the time. You won't see any jerky motion if you do that, but don't try to run dozens of NPCs with such settings if you don't have a powerful machine!)
• Smooth camera movement, which gives a much nicer 'feel' to the game. Work remains, however, as besides smoothing the camera's movement it also needs to be 'smart' - to move to an appropriate position when in a cramped area, for example. This might be a fun little project for someone thinking about contributing to the Intensity Engine.
• Various minor bugfixes, as I find them.