New Script Tutorial/Docs

Continuing the recent trend of writing docs, I wrote a new scripting tutorial, which is now present in the git repo. See

docs/scripting.markdown

That document refers to the example scripts in

docs/scripting_examples/

This should be a clear and easy way to get started with scripting in the Intensity Engine. I'll add more examples later on.

'Making a Game' Tutorial

There is an increasing amount of interest in using the Intensity Engine separately from syntensity.com, in some cases without a master server at all (like, say, for a singleplayer game). The engine supports this very well, but documentation has been lacking. So, I started to write a tutorial for that. Feedback is welcome.

Rain Effect

Somebody on IRC mentioned today that a rain effect would look nice, so I made a quick one:



Note how the rain is realistic in that it falls until it hits something, then shows a splash. So there is no rain inside the castle or underneath the scenery. This takes a little CPU, so very heavy rain (thousands of drops at once) might slow you down. In the video there are about 1,000 and speed seems ok.

The effect is about 40 lines of code, in library/1_3/CustomEffect.js. You can see it in action if you run the latest git, and play the storming_test map.

Editing Tools in JavaScript

The video shows a 'slope tool' that makes it easy to create sloped surfaces in cube geometry. It isn't finished, but it shows what can be achieved by this approach, I think.

Basically, this is done using new JavaScript API bindings to editing code that works on the cube octree. Actually the editing code is fairly old - it was used already in a very early version of the Intensity Engine - but it was not enabled in the current JavaScript API until this week.

Using the expressive power of JavaScript, it is easy to create editing tools like this one, for all sorts of purposes. For example it can be used to import maze files to create maps with them, etc.

You need to run the latest compiled engine for this. The code is in library/1_3/Editing.js, and you can see it in action in kripken/editdemo, which you can run by entering that name into the server_runner plugin GUI, after logging in to the master (see README-standalone.txt). To see it work as in the video, do /actionkey0 when hovering on one corner, then the same command when hovering on the opposite corner (this is just for demo purposes, not how the final controls should be).

Move to a Permissive License? (Part 2)

This is a followup to this post.

Following the previous post, I got some feedback in comments and on IRC. Here are some of the points raised, and comments on them:

• It was pointed out to me that zlib is the most permissive license of those mentioned, allowing binary copies to be made without attribution, whereas BSD still requires that you keep the copyright notice in that case (so you don't need to distribute the source, but you do need to document that you are using code written by whomever wrote it). It seems MIT does the same thing, but the wording is slightly less clear - BSD explicitly mentions source and binary distributions, while MIT just talks about 'copies of the software' (which many people seem to interpret as intending both source and binaries, but I would have expected to see something like 'copies or transformations of the software', where 'transformations' means compilation to binary form, etc.). So, out of zlib/BSD/MIT, I lean towards ('new') BSD.
  
  
• I should clarify my goals with the license change. There are basically two: First, I want the code to be useful for people, however it can be, which includes making money off of it in commercial games. My second goal is to improve the situation of open source in gaming - which is currently one of the last fields of software almost entirely dominated by proprietary code (compare the situation to operating systems, web browsers, web servers, databases, programming languages, etc. - open source is doing very well in all of those). I guess the two goals are not necessarily in perfect alignment, hence the need to think carefully about the license.
  
  
• Also I should clarify my own personal goals&status: I am looking for a job right now, so I will likely have less time for this project than I have had, but I certainly intend to continue contributing. Anyhow since we are past a stable 1.0 release, and the engine is in very good shape, really what we need now is more people creating games with it rather than more engine features that I add.
  
  About my role in the project, I would be very happy if the development team were to expand, and have more sharing of responsibilities. I've been talking to related projects and various people about that, and hopefully there will be progress on that front soon. Permissive licensing might make that easier, since with GPL projects it matters who owns copyright, whether you have copyright assignment or not, and all that, whereas in permissively licensed projects it is far less of an issue.
  
  
• I've been looking at open source code that is successful in gaming, for inspiration. Basically three projects come to mind, detailed below. I'm not sure what lesson to learn from them yet, but they are worth thinking about.
  
  
  • Quake Engine(s): Released as open source some time after the commercial releases, GPL with dual licensing. The GPL option has been used extensively in the open source community. However, the GPL uses did not become a significant force in gaming. Basically the GPL code releases play catchup, always being behind the closed code. Also, it is not certain that GPL code releases will continue after id Software was acquired by ZeniMax.
    
    
  • Ogre 3D: Used to be LGPL + optional commercial licenses, has moved to MIT. It is not clear yet if moving to the MIT license will change anything, as Ogre 3D was already doing very well before, including being used in commercial games. I am guessing that Ogre 3D has support for consoles, but that code isn't in the public repo (likely it can't be, because of the console SDK terms of use), which leads to a quasi-dual licensing model: Free for use (MIT) on regular computers, requires a license for consoles (or, implement all the console integration yourself, in theory).
    
    
  • Bullet: zlib licensed. The Bullet physics library is very popular, and has been used in many commercial applications, including ones that significantly modified Bullet, presumably without contributing changes back (but not sure). Unlike Ogre 3D, Bullet can be used on consoles freely, as there is really no need for special console integration code.
    
  
  

Move to a Permissive License?

I am considering relicensing all the code I wrote in this project to something more permissive, like zlib, BSD, Apache, etc. - basically, to let people use the code entirely freely. Please let me know whether you think that is a good idea or not, and if it is, which license we should switch to. This is a big decision - involving some 65,000 lines of code (about the same as Cube 2, btw) - so it should be done carefully.

As background, I chose the AGPL when I started, because I wanted to keep open the possibility of dual-licensing (to generate income for the project), and to make fragmentation of the community less likely. The situation with both of these has changed: I don't intend to make money myself from this project anymore (I still think it can be done - but it would take time, and before that time arrives, I will have run out of money myself...), and so far there seems little worry of fragmentation and incompatible forks.

So, I am considering moving to a license like zlib/BSD/etc., which are simpler and make life easier for people using the code - clear benefits, and could lead to more people using the code. Of course the flip side is that the code could then be used and modified in closed source projects without returning anything to the community. These are the usual tradeoffs between the BSD and GPL approaches.

Some thoughts on possible licenses:

• zlib: Same license as Cube 2, so kind of simple in that respect - a single license for almost the entire project (almost, because things like V8, ENet, Django, etc., have other licenses).
• BSD: Probably the most common permissive license out there, and the most familiar to people. Also worth mentioning, zlib is not an option on Google Code, while BSD is.
• Apache: Permissive, while adding some patent protections, which is useful. However, it does make the license text quite long and complex compared to zlib/BSD/MIT, which is a downside. Another downside is Apache is not compatible with GPL2, but is with GPL3. There are many codebases out there that are GPL2-only (including ones relevant to this project) so that is an issue.
  
• LGPL, MPL, etc.: More permissive than GPL&AGPL, but still some requirement of giving back, at least for changes to existing code. If the license is to be changed, I kind of tend not to go this route, because the current license is already quite close to it, since we don't consider games to be derivative works anyhow, which makes our AGPL sort of like the LGPL in that respect (a good comparison is how the Linux kernel is GPL, but you can run apps in userspace that are not GPLed). So really the actual change in going to one of these licenses is the removal of the 'A' from AGPL, that is, removing the condition of providing the source even if running over a network.
  

So, again, I am looking for feedback on this topic. We can also hold a vote if there are strong opinions and that makes sense. One thing though: Please let's not make this into a GPL vs. BSD flamewar with all the usual arguments we have all heard before - I ask that the discussion be about this project, which license makes sense for it (and not which license in general is 'better').

EDIT: Followups in this post.

Running Locally & Singleplayer

The server runner plugin can now work entirely offline - without connecting to anything remote, not even a master. In such a case it will run using the local files. Basically, running a map is now as easy as entering the name of the map in the GUI and clicking 'start'.

In such a situation you don't have any of the benefits of the master server, like getting the latest version of the game, being able to upload changes, play multiplayer or co-op games, etc. But, it is useful for when you don't have a network connection, for demos, or if you just want to run entirely standalone - like for a singleplayer game.

Speaking of singleplayer games, in a few lines of script the client can now be set up to automatically run a certain map using the plugin, which would basically turn the client into a single-purpose game: Start the client, and that game runs. If you also change the branding (logo, menus, etc.), it is now easy to use the Intensity Engine for your own singleplayer games.

(The underlying functionality for these new features is that you can set [Activity] force_location on the server, and it will run the map with that location, without querying the master. It will also communicate that fact to the client, so it does the same. The server runner plugin basically runs the server in a transparent way, with that feature enabled.)

Local Server Runner Plugin

People have complained that local editing and playing were harder than it should be. A plugin that I finished writing today, server_runner, should help with that. When the plugin is active, you can start a local server with just a few clicks in the GUI. The plugin will run the server in a separate process (so if your scripts crash the server, the client won't crash - kind of like how modern web browsers run plugins in separate processes).

Usage:

• Activate the plugin: Add intensity.components.server_runner to [Components] list in your settings.cfg
• After logging in to the master, click on 'plugins...' in the main menu. You will then see the status of the local server.
• Tell the plugin which map to run (simply by writing the location of the map, e.g. "racetrack" for the racing map). Then click start, and wait a bit while the server is started up for you. As soon as it is ready you will automatically connect to it.
• The server will be shut down automatically when you close the client, or connect to another server, so no need to worry about that. You can also shut it down in the GUI if you want (which is necessary to start it up with a different map).
  

Limitations:

• Requires you to be logged in to the master, but allowing master-less running would be possible if people want it.
• If the server crashes, output is saved to ~/.intensityengine_client/out_server.txt (note: not in the install directory, but the engine home directory). A nice GUI for viewing the output should be added later.
• You can't write the location of a map that you never played on before, as it only looks locally for translating the map location to the asset info.
• Tested on Linux. Should work on other OSes (it is 99% pure Python), but not tested yet.
• The server still uses a network port, so your firewall may ask about that. It would be possible to move to a pure IPC solution later, without that problem, but it would be additional work.
  

You must be running the latest git source code to use the plugin. If you do, I'd be happy to hear feedback on how things work.


Background:


Sauerbraten, the engine that the Intensity Engine is based on, lets you easily run a local server - it runs the server inside the client, in fact. This makes sense, since the Sauerbraten server is very simple, it is basically a network message router.

However, the Intensity Engine lets you run scripts and physics on the server, which raises the possibility of the server crashing (due to bugs in scripts, etc.). The server also can take a lot more CPU and RAM because of that. Consequently, the server is strictly separated from the client - there is no option to run it inside the client. Another reason is since the server now does a lot of the things the client does (scripts, physics), then maintaining a single codebase with the server defined as separate - and not two options, separate or internal - is much easier.