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.

Procedural Generation

Creating a landscape can be a time-consuming task. Because of that, it is interesting to consider procedural generation, where you let a script do the work for you. Classic examples of procedurally-generated terrain are fractals; they are a simple but effective way to create realistic-looking landscapes, and also things like trees.

As the Intensity Engine is already integrated with Python, it was a natural idea to script the generation of terrain using that language. So, here is an example of a giant spiral generated by Python:


That's what it looks like from the ground, and this is what it looks like from above:



This is generated by a short Python script, basically just to implement the equation for the spiral, which is something like x = r(t)*sin(t), y = r(t)*cos(t), z = h(t), where r(t) is a radius, r(t) = a*t+b, and h(t) is the height, h(t) = c*t. t goes from 0 to 1. It's pretty much that simple.

The real work was in processing the output of the Python script in C++. This is done by a general algorithm (not specific to the spiral - it can be used for anything) that generates appropriate Sauerbraten cube geometry from the raw data, and then applies some smoothing to the result to make it look more natural. The code appears in editing_system.cpp if you are interested.

Using that code, one can now create a lot of different types of scenery automatically. I have so far made some examples, of a sphere (which isn't perfectly round - it needs more smoothing) and staircases. These are the sort of things that can be tedious to do by hand, that Sauerbraten mappers currently spend a lot of time on. In fact it is possible (minor tweaking might be needed though) to perform procedural generation in the Intensity Engine and then import that map into Sauerbraten, which would open up a lot of interesting possibilities for Sauerbraten mapping (contact me if you're interested and I'll help out). The code might also be ported to Sauerbraten, but that would not be trivial as it relies on some Intensity Engine specific features (Python integration and loading of maps on the server).

A video of the spiral, and it's creation process, can be found on the screenshots and videos page.

Ogre - Deferred for Now

I have decided to temporarily suspend Ogre development at this point. The screenshot above shows the state I managed to get it to thus far. You can see there a floating white object, which casts a dynamic shadow rendered with Ogre. Note that the dynamic shadow and the static shadows from Sauerbraten are combined in a reasonable manner, in particular where they overlap they don't create a yet darker area, which is the result you get with the simplest shadowing approaches.

To prevent that problem, I added an alpha channel to the static shadows, which is used to combine them with the dynamic shadows (but not with the diffuse textures). In effect, dynamic shadows are suppressed in areas of static shadow. This has a few drawbacks - in particular, it is hard to get the dynamic shadows to be as dark as the static ones, lightmap textures are 33% larger, and static lighting is not as vivid as it might be - but a better solution would require writing custom shaders.

But shaders would be required anyhow as depth shadow mapping in Ogre requires it (I was hoping this would be easier, but it isn't), and without depth shadow mapping you have various problems with shadows (casting in the direction of the light, not just away, etc.). I don't intend to make a serious effort at this point in time to design appropriate shaders and so forth. So Ogre will wait for now, until someone decides to work on it.

However, a great deal of the required work has already been done: Set up Ogre correctly; feed cube geometry into Ogre; synchronize entities to Ogre (lights, etc. - Ogre's dynamic shadows must have the same orientation as Sauerbraten's static shadows!); utilize Sauerbraten's lightmaps; and so forth. All that is really left is to write shaders for shadowing, and some interfacing for odd bits and pieces (particle effects, etc.). So, when I or someone else returns to the matter of Ogre rendering, it shouldn't be too hard to finish the job. It's just that there are more pressing things at the moment (in particular a 0.2 release).