Local Storage Plugin

A new plugin has just been committed, local storage, which lets you store key-value pairs locally. It's currently being used to persist the high scores in the Racing game.

Usage:

• Add intensity.components.local_storage to the proper place ([Components] list) in your settings.cfg, so the plugin will be loaded.
• In your scripts, do CAPI.signalComponent('LocalStorage', 'read|KEY'); to read the value for KEY. You will get in response a string (all output from signalComponent is in string form), so do eval() on that. The result will be a list of responses from components. Normally you will have only one storage component, so just get the value at index [0].
• To write values, do CAPI.signalComponent('LocalStorage', 'write|KEY|VALUE'); to write that KEY-VALUE pair.
  

That's basically it. See also the source file for some technical docs and notes.

Per-Client Variables

By default state variables are synchronized between all clients: changes to data are reflected everywhere. This is simple and appropriate for most FPS games. However, some information should only be sent to some clients, like say the inventory in an RPG game. Library 1.3 now allows such state variables, which are called clientPrivate.

A clientPrivate state variable is only sent to the client whose avatar that is. In other words, clientPrivate variables on a player entity are only updated to that player - other clients will not see a value for that variable on that entity. (Note that clientPrivate has no effect on non-player entities.) Of course, the server sees all of the values (and when it updates one, the update is only sent to that player).

Here is an example of how to add such a variable to a logic entity class:

• secretItem: new StateString({ clientPrivate: true }),

Library 1.3

library/1_2 has been forked into library/1_3. The goal is to keep 1_2 as it is, so all the older games still work, while development moves on to 1_3 (which may include API changes, etc.). So, for new games, 1_3 should be used, especially if you will need new library features, as those will be added to library/1_3.

To migrate a map to 1_3, currently the following is necessary:

• Remove the map asset dependency on library/1_2 and add one for library/1_3.
  
  
• The map script should include the following line before any other Library.include commands:
  
  Library.include('library/1_3/');
  
  
• Imports of 1_2 libraries should be changed as follows:
  
  Library.include('library/1_2/Projectiles');
  
  should become
  
  Library.include('library/' + Global.LIBRARY_VERSION + '/Projectiles');
  
  (this way of doing things will help make future library migrations much easier).

After doing those, the map should work exactly as it did with library/1_2.

1.1 Release

Revision 1190 is tagged as version 1.1. Binaries for Windows and Ubuntu 9.10 are on the Syntensity Mod DB downloads page. I'll link to them from the main website's download page after a little more testing (if you test them yourself, please say how it went, here, on IRC, or in the forum - thanks!).

The new version has many changes, but most won't be noticeable until maps use the new features. The improvements include:

• Enable maps to customize move, strafe and jump
• Support for cutscenes
• WoW-like mouse movement in Mouselook mode - cursor at borders will rotate the view
• Allow client and server to (naively) share their home dirs, and do this by default when the server does not specify a home dir explicitly. This makes it much easier to set up a local server.
• ZeroG module, allowing maps to have zero gravity, custom gravity effects, etc.
• Vehicles module, to let entities move like simple vehicles (pitch based on floor, thrust for movement, etc.)
• World.getSurfaceNormal, which allows doing bouncing physics entirely in scripts, + Grenade example
• WorldSequences module - lets you track players progression through areas
• WorldSignals module - lets you emit and listen for signals that are relevant to areas in space
• New Steering module for bot movement control
• Add absolute x,y to clientClick, allowing maps to have menus
• Allow scripts on the server to intercept and handle text messages (e.g. can be used as a simple way to let people issue commands to the server, etc.)

Launch: Syntensity Open Beta, Intensity Engine 1.0

Today we are officially launching Syntensity's open beta, as well as releasing version 1.0 of the Intensity Engine. This brings to a close an intensive year of development, but is also just the beginning for this project.

Instructions for getting started with Syntensity can be found on the main page.

Syntensity's open beta launches with one complete game (the gk1 map, which is an insta ctf-type game that also has some automatic gun turrets). But Syntensity is really more of a platform for game creation, not one or two games that we created ourselves. This initial game is just to show what the engine can do, and also to be a basis people can work from (by modding gk1). We'll be making some more example games during the beta (to show more of the engine's capabilities - gk1 covers only a small part of that), but our main focus will be to help people use the engine to create the games they want.

Regarding the Intensity Engine (the open source project that comprises Syntensity's code), it is now at 1.0. It's basically feature-complete for our initial goals, and decently stable - enough for people to start using it, both for Syntensity and other projects. There are some bugs we are aware of, and testing will probably uncover more, but overall things are in fairly good shape. In the near future we will focus on fixing bugs and polish, later on, there are a lot of engine features on our roadmap.

Automatic Testing: Client and Server

(This will be a mostly technical post.)

There is a lot of work planned for the engine after the launch of the open beta (which is, btw, just about here), so automatic testing is crucial to prevent regressions. Basically, every time you commit a change, you want to be able to run a completely automatic battery of tests that checks you didn't break anything. So far in the Intensity Engine only the master server had automatic tests for it, using Django's test client. Those tests are actually very comprehensive, and have already come in handy. There are also some unit tests for the JavaScript API. But for the client and server as a whole, writing automatic tests isn't as easy: They don't have nice test setups like Django, and what's more, the client is a GUI program, using OpenGL (if it were using a GUI like GTK or Qt, there would actually be some tools to help out).

The tests/ directory contains what I did so far towards this goal, over the last few days. The test setup uses pexpect, a very useful Python module that lets you communicate with processes, sending them input and checking their output. This, combined with the server's Python console, lets the server be tested in a nice fashion: Start the server in a separate process, issue it commands - for example, check such and such state variable of such and such logic entity - and validate the output. Using Python's unittest module, in each test the server environment (home directory, with downloaded assets and so forth) is created from scratch. So all of this together gives an appropriate way to test the server.

The client was a little harder. First off, I added an option to run a Python console, just like on the server (which took some refactoring of the console code). Then, I had to write bindings for 'injecting' user events. That is, by issuing commands through the Python console, the test runner can manipulate the client as if it were an actual person: Move the mouse, click, press a key, and so forth. This took some time to get working correctly, due to how SDL events behave and how the engine processes them. But it appears to now be working as it should.

Currently there are 4 tests. Each of them starts up a master, a server, and a client, runs a map ('storming') and then does one of the following:

• Modify a state variable on the client and see that it propagates to the server
• Modify a state variable on the server and see that it propagates to the client
  
• Modify a state variable, restart the map, and see that it returned to the original value
• Modify a state variable, upload the map, and see that the new value is used

In other words, these are high-level functional tests, and they already cover most of the basics: Starting up the client and server, loading a map in each, network synchronization, and map uploading. In particular, they cover basically what someone starting out with the Intensity Engine would do (if they follow README-standalone.txt). So these tests are a good start, while of course many more should be added over time.

The tests take about a minute to run, what with creating an entirely new environment for the master, server and client for each test, and starting them all. (Also, for some reason the injected SDL events are slower than I would expect.) But it's actually kind of funny to watch the tests running, with the mouse jumping around, clicking and keypress sounds, and so forth. (Although I imagine I will get tired of it soon enough, and just go do something else while the tests run...)

Sketch World Demo

I had some spare time today, so I made a simple 'Sketch World' activity:



You can see the code here. What's nice is that this takes only 165 lines of script, and that includes full multiplayer support (everybody has their own color to draw with, sees everyone else's drawings, etc.).

Intensity Engine 0.9.6

I had hoped to release version 1.0 of the Intensity Engine before the end of the summer, but the final remaining task - some nice example maps - hasn't worked out yet. There seem to be two main problems:

• It's hard to get maps with commercial-friendly licenses (like CC-BY-SA), which is a requirement for inclusion in the Intensity Engine. There are two main issues here: That some mappers don't want to release their work under such a license, and that many or all existing maps use textures and models that have limiting licensing.
  
• A typical chicken-and-egg problem: Release a stable 1.0, and people might start mapping with it, but to release a stable 1.0 we need some maps.

So, the 1.0 release of the Intensity Engine is still pending. However, that won't delay the launch of Syntensity, which should be in a month or so - preparations for that are going well (and it doesn't have the two problems mentioned above).

So instead of releasing version 1.0, I have meanwhile partially lifted the feature freeze on the Intensity Engine, and the current version is now 0.9.6. Changes include:

• New master server, written from scratch using Django and CherryPy. The old minimaster and asset servers are deprecated (asset storage is now a component in the master server)
  
• JPEG 2000 support, for significantly smaller downloads (at the cost of decompression delays after downloading)
• Copy-paste of entities when mapping
  
• Component and signal system for the client and server
• Plugin system for the JavaScript API, and several example plugins (projectiles, etc.)
• Allow custom animations (up to 128) per model
  
• Enable the Cube 2 ragdoll system
• Config file autogenerator and converter (from Cube 2 configs)
  
• Improved textures for water, lava, etc.
  
• Various bug fixes
  

Article on Maxping

Here.

Intensity Engine 0.9.5 Release

More screenshots can be seen here.

Since 0.9, a month and a half ago, a lot of work has gone into the 0.9.5 release which is out today (rev. 324). This release is still not considered stable, but is a significant step towards that (in fact it may be the last release before 1.0). Two main areas of focus in this release are:

• Allowing people to run their own infrastructure - master server, asset servers, and server instances - without any connection to Syntensity. This allows both federation (separate independent servers, with loose connections - like the WWW) and makes it easier to customize the Intensity Engine for non-standard uses.
  
• Improving content creation and collaboration. This is now in a good enough state to allow focusing on content creation, which is one of the main tasks remaining before the Intensity Engine 1.0 release and public launch of Syntensity.

In more detail, here are some of the changes:

• 'clientSet' state variables, which are applied first on the client, allowing better responsiveness in an easy way
  
• Initial login to server instances made faster
• AreaTriggers made significantly faster, and now work correctly on server
• Allow maps to extend the position protocol messages, for faster updates of map-relevant information like custom animation settings
  
• Allow rendering models (including players) from map scripts, for more flexibility in visuals
• Added almost-finished Stromar character model
• Update of server-side NPC/bot system to current API
• Various API extensions (e.g., allowing gravity to be changed)
  
• Various minor GUI and usability improvements
• Full support for building on Ubuntu 8.10, Ubuntu 9.04, Windows XP and Windows Vista
• Plenty of bug fixes
  

Binary builds aren't planned for this release, as things are still moving quite fast.


Towards 1.0

The Intensity Engine is now in feature freeze. Only bugs in existing features will be fixed for the 1.0 release, which is dependent upon

• a decent level of stability and polish, and
• a reasonable amount of working content that can be distributed with the engine or at least used to demo it