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.
  

Initial TideTurner Gameplay Concept

/trunk now contains a very preliminary concept demo of some ideas for TideTurner, here's a video:



I'll have to figure out how to improve the clarity when I prepare a video for the 0.3 release. But here is what you should be seeing:

• The player controls a character that can cast spells. Two spells are shown: Creating a skeleton minion, who fights for the player, and creating a force barrier to keep enemies away.
• Casting spells takes energy, which regenerates, so the player needs to decide which spells to cast at what time.
• Enemies arrive from two entrances to fight the player and his minions (the enemy skeletons are in red).
• A successful strategy should probably involve blocking one entrance while summoning enough minions to overcome those flooding through the other one.
• The force barriers - shown as semitransparent yellow - vanish eventually. Not preparing for that can lead to your demise, as shown in the video ;)

You can playtest this yourself right now, by compiling and running /trunk (use bzr lp:intensityengine to check it out). Revision 209 is what is shown in the video, by the time you read this a later revision might be current (which might be different or even broken; revert to rev. 209 if so). Note that you might need to start with a fresh server for things to work correctly, depending on what you currently have in /storage. This can be done simply by deleting the /storage directory under the installation directory, but note that this deletes all of the server's data, so if you have any maps of your own, back them up first.

Skeletons in /trunk

Work on TideTurner led to various bugfixes and small feature improvements in the engine during the past week (for example, more uniform handling of positioning for both static and dynamic entities). It's always the case that actually using a product leads you to find all sorts of small things that you don't think of during development...

/trunk should now contain a usable environment for testing of TideTurner: I imported all the media files, etc. - I don't like the idea of large binary files in a version control system, but really there is no alternative. I'll also try to set up a hosted server so that multiple people can playtest at once (I need to recompile the server for the appropriate distro). Finally, I set up a section in the forums for discussion of TideTurner development. Meanwhile, here is a random screenshot:


The main character model is by Tiziana aka TiZeta and the skeleton by Adam Ward aka Gixter. Both are models that can be used freely. I intend to replace them eventually, once I find an animator to work with on this project, but for now they should be good for playtesting.

The initial game idea is for the main character to have a few spells, one to summon a skeleton, another to create barriers (you can see one in the screenshot, it's the semi-transparent yellow area), and maybe a fireball for combat. The character will then fight another group of skeletons, perhaps led by another player, with the barriers being of stategic importance, to prevent your opponents from surrounding you, giving you time to regenerate health (the barriers will vanish after a certain time period, or if they have been damaged enough), and so forth. So far in trunk you can create barriers with a click and skeletons with a rightclick, and clicking on a skeleton makes it walk to you - still in a very early stage here.

Here is the code in charge of creating barriers:

create_barrier = StateArrayFloat()

BUTTONS_TO_SPELLS = { BUTTON_LEFT : "create_barrier", BUTTON_RIGHT : "create_minion" }

def click_action(self, button, x, y, z):
    self.clear_actions()
    self.queue_action( SpellcastAction([x,y,z], Commander.BUTTONS_TO_SPELLS[button]) )

def can_modify_create_barrier(self, value, actor_unique_id):
    self.barrier = create_logic_entity(Mapmodel)
    self.barrier.model_name = "forcebarrier"
    self.barrier.position = value
    self.barrier.yaw = yaw_to(value, self.position)

    return False # No need to change this value on the clients

It might not be entirely self-explanatory, as you need to have an idea of what StateVariables are and how can_modify_X functions work, but I think it does show how only a little Python code is necessary to do stuff like this.

Two minor updates

1. Today I thought about how map creation could be made more convenient. In particular, I was unhappy with the fact that cube geometry is saved in .ogz files while entities are stored in the database, and so far in order to copy that entity data I've basically been doing SQLite dumps. Now, it does make sense to separate the two kinds of data (cube geometry is static, while entities are not, in particular, you might want to take 'snapshots' of entity activity for various reasons), but being forced to use database exporting is not good.
   
   So it seemed a reasonable idea to write dump_entities() / read_entities() functions, which would save all current entity data to a file and read such a file, respectively, in a portable manner (so it doesn't matter what database you're using, if at all).
   
   At first glance, it wasn't apparent how hard it would be to write such functions. But after a bit of thought, it became clear that my hard work from earlier in the project's history would pay off. For one thing, in the Intensity Engine we do entity lifecycle management is in a unified, high-level manner. For example, there is a single create_logic_entity() function, which encapsulates differences between Sauerbraten's dynents and extent data types. Another useful architectural feature is that we store all entity information in just one place: its StateData (well, to be accurate, two: there is also the Class field). Finally, the Intensity Engine has a clean separation of database operations from everything else, that is, creating entities and storing them in the database are conceptually and practically separate.
   
   As a result, dump_entities() and read_entities() take only about 10 lines of Python code each :) It's definitely a good sign when adding features is as easy as that.
   
   
2. A second issue I'd like to mention is that following a suggestion from SephoD on our forums, I looked into generating scenery from a heightmap. This differs from the procedural generation approach I did previously in that it uses a 2D heightmap instead of 3D full/empty information.
   
   This is a little trickier than 3D scenery as for heightmaps we want a finer resolution, which necessitates a lot of cube corner pushing, and there are issues with cube alignment boundaries (cubes can only be made at coordinates which are powers of 2). So far I have some partial results:
   
   
   
   (Click for a larger version.)
   
   Admittably this isn't terribly clear, but it shows a large 'valley'. Note that particularly near the center of the valley there are some artifacts, these are alignment issues that should be smoothed out in the future. They actually give an interesting effect, but that is completely non-intentional ;) In any case, the code is already useful for mappers that don't mind doing a little manual smoothing after the heightmap is generated.
   

Planning a Game

Version 0.2 of the Intensity Engine has been released. Highlights include procedural generation support, faster NPC movement and CEGUI 0.6.2b (for the full announcement see our forum). This incremental release includes most of the basic features I want to have in the engine at this point. I'll be constantly adding more, but major features will wait, as I am now going to focus on creating a game with the engine.

Towards that goal, I'm looking for people to team up with. Specifically, I'm looking for two people:

• a 3D artist/modeler
• a (C++) coder

Formal experience is unnecessary, as long as you know enough to get started and are motivated to learn and improve.

The codename for the game is TideTurner (the actual name will be determined later). The general game concept is a third-person action game, with the players leading NPC minions in battle. Aside from that, the specifics are yet to be determined. Playtesting will decide which ideas end up in the game and which don't.

If you might be interested in collaborating on this game, let me know, on IRC (#intensityengine on FreeNode), or by email at kripken -at- intensityengine dot com. Note that the engine is open source, but that does not preclude the game from being commercial. In particular, we can try in-game advertising to make money. Profits will be shared among all team members, of course.