Skip to content
Ingo Ruhnke edited this page Mar 22, 2015 · 5 revisions

The following text is written by Grumbel.

Windstille has been in development for a long long time. However not all things went smoothly, so development died down more then a few times. So time to document a few things that went wrong in the past and how I intend to fix them.

Wiki

While Wikis are nice for some things, they can easily clog up with way to much redundant garbage if they aren't maintained properly. The user editability also leads to plenty of pointles discussion. To cut the noise down, to make it easier to reorganize things, to make it easier backup things and to make things less maintainance intensive, the Wiki got moved into SVN and is now generated offline.

If people want to discuss the content of the Wiki they shall use the mailing list or IRC.

Tilemaps

While tilemaps are a classic building block of 2D games, they just didn't work out for what I had in mind. There is to much flexibility that is lost due to them and there are quite a few things that are made much harder, like slopes, AI reactions to the environment, etc.

The level, in terms of graphics, will be a series of textures quads that can be freely placed. The collision geometry on the other side will be a series of line segments, this concept is called Navigation Mesh. When a player walks, he will follow those line segments instead of constantly checking a tilemap. This will lead to a kind of on-rails gameplay instead of a more freeform one.

Some code for this is in place and availabe in a test application, it is not hooked up into the game.

Some support for Tilemaps might be kept, since they are somewhat useful to get a base graphics done. However its not clear if real tilemaps will be keep or just some surfaces that can be docked together.

Vertex Animation

For the time being we might stick with Vertex animation, since they already work, but bone based animation is really the target.

Vertex animation looked like and easy target and it kind of was, we have them implemented in the game. However the size of the files grew quicker then expected and a lot of flexibility is lost with vertex animation (i.e. no easy way to change clothes, no easy way to seperate animation from the mesh, etc.). Bone based animations are needed.

Story

To much time was wasted on discussion about backstory and stuff and to little with things that could be turned into actual gameplay. A prototype level that demonstrates dialog and overall gameflow is therefore a priority.

Dialog

Windstille currently has a JRPG like dialog system, that presents a portrait along with text. It sort of works, but creates a very blocking experience. One of the goals of Windstille is to be as non-blocking as possible, meaning that you shouldn't be forced to click on people and then wait for the talk to finish, instead dialog should be more natural and for example be initiated by NPCs automatically. Dialog should also be focused on allow voice acting later one, which JRPG style systems are terrible at.

Long story short, the new dialog system will be more like the classic LucasArts advetures, presenting color-coded text right on the screen without necesarrily block.

Conversation, aka answering to dialog, is currently done by a system similar to Dreamfall, it presents a general topic choice, along with a little text for thought of the character on the topic. So basically a normal multiple choice system with a little twist. This might mostly stay as is, maybe taking a bit additional inspiration from Fahrenheit and Mass Effect (i.e. displaying the choices while the dialog is still running, thus more fluent and less need to wait on choices).

Another issue with Dialog is scripting, current dialog is heavily scripting based, for longer dialogs this is impractical, a system similar to Adonthell shall be used, i.e. an aproach based on data (s-expr files), not on script code. Scripting will be done via hooks in the data.

Editor

Flexlay, while usable and working, is based on an old version of ClanLib. This isn't all that good in the long run, since it limits the GUI quite a bit. Current plan is to rewrite the Editor and make a sandbox editor based on Gtkmm, that will allow to edit the levels in engine itself.

Prototypes

In the past there was some confusion what the final goal actually is, to get this sorted out development shall focus on developing prototypes of key game mechanics and plenty of sketches of location.

Navigation Mesh

The Navigation Mesh Prototype should demonstrate the concept of the navigation mesh level layout and demonstrate actions like jumping, ledge grabbing, etc. performated on the mesh.

Shooting

The shooting test shall demonstrate the shooting, the aiming with laser pointer, as well as flamethrower action.

Moving the goalpost

Windstille as shifted targets quite often, so its time to get things documented properly and tested properly in prototypes, so that the actual game can improve on a more constant basis, instead of randomly jump from one half finished tasks to another half finished one and thus end in an unfinished mess.

Clone this wiki locally