FreeGameDev Planet - Development

Also check out the games planet.

November 21, 2014

OpenXcom

November 18, 2014

Spring

November 17, 2014

Cafu

Reintroducing "layers" (aka "groups") to the Map Editor

A while ago, in September, I considered it a good idea to remove the "groups" feature from the Map Editor. This was fueled by the observation that entities too can naturally and inherently serve for grouping the individual elements in a map. Keeping a second, explicit mechanism for the same purpose (the "groups" feature) only seemed to be a redundant burden. Therefore, the intention was to turn the existing two methods for grouping into a single method, to be implemented by having entities subsume the functionality of the former groups, thus making groups fully redundant so that they could be removed without loss.

Alas, after the change was complete and a considerable effort had been spent to make entities and entity hierarchies work as well as groups did, the first tests and feedback quickly showed that it didn't work out, and that my assessment of the situation (and my enthusiasm for entities, or in fact, the entity component system) did this time not lead to the desired solution. Practically speaking, we found that the "groups", as they were implemented before, were just too good and too convenient to be removed: my attempt to achieve the same with entities was just not on par (think e.g. of the "Hide Other" button). Considering this more closely, it turned out that this was not a problem of the implementation, but of a more principal nature:

Entities and their hierarchies are an excellent way to organize (group) map elements in terms of the game or the virtual world that is being developed: You use entities to model game objects like players, opponents, cars, lifts, or anything else that is relevant for the game.

Groups, however, serve a quite different organizational purpose that, in hindsight, is orthogonal to that of entities: With groups, you express features that are important to the map designer's workflow or are of technical relevance – but not to the logical modeling of a virtual game world.

mapeditor_groups_contextmenu.png
Image Detail Image Download

Therefore, I'm currently working on undoing the commits that removed "groups" from the Map Editor, and on reintroducing them soon. At the same time, I will take the opportunity to rename the former "groups" to "layers", because "groups" is a too general word (entities group map elements, too!), whereas "layers", with their analogy to 2D drawing programs, seem to describe the purpose of the feature in a more precise and more intuitive manner.

In summary:

  • Entities group map elements by their logical meaning in the virtual game world, as observed by players, as needed by script authors, as seen by the core engine, etc.
  • Layers group map elements to facilitate technical details for the map designer, e.g. to temporarily hide objects, to lock them from being accidentally modified, etc.

Note that this is currently still a work in progress: I'll post here again as soon as the reintroduce-groups branch is completely implemented and committed. :up:

by Carsten at November 17, 2014 05:32 PM

November 16, 2014

Castle Game Engine

New exciting Spine improvements in our Castle Game Engine! Spine allows to create great 2D game animations...

New exciting Spine improvements in our Castle Game Engine!

Spine allows to create great 2D game animations, that can be used within our engine. For example https://www.facebook.com/Venicethegame uses Spine with our engne :) New wiki page https://sourceforge.net/p/castle-engine/wiki/Spine/ documents Spine support in the Castle Game Engine.

Recently implemented Spine features:

1. Slot color and transparency can be animated.

2. Slot draw order can be animated (by "draw order timeline").

3. Using Spine model without an atlas is possible. Expects images in images/<attachment-name>.png files. Note that without atlas, we lose some speed (texture switching) and even quality (textures may be resized to power-of-2 on some GPUs; atlas avoids it by always creating an atlas page with power-of-2). So atlas is still advised, although it is not required anymore.

4. Start of skinnedmesh support. The skinnedmesh in setup pose is affected by bones correctly, and during animation it moves as a whole (is affected by parent bone transformation). Missing is the ability to recalculate vertexes affected by bones during animation (that is, to deform skinnedmesh during animation).

5. NavigationInfo.blendingSort X3D extension allows to force blending sort by VRML/X3D author to NONE, 2D, 3D. Spine models automatically include blendingSort=2D, so they just open Ok in view3dscene (http://castle-engine.sourceforge.net/view3dscene.php). You may find useful to use blendingSort=3D for 3D scenes where there are many transparent 3D objects visible over each other.

November 16, 2014 01:29 AM