Warzone 2100 Forums

aubergine, why not, we only need someone to create new converter (I'm busy currently).

I still don't know enough about the plethora of config files that define the tech tree so I wouldn't be effective at getting it done.

My current approach is to try and build a large spreadsheet containing all the data, but it's a very tedious and time consuming task. I chip away at it every so often when I can muster the will to page through reams of information from multiple sources.

What I'd ideally like to see is some way to get this JSON file created, then the game itself could use that instead of gazillions of text files. And it would be relatively easy for anyone with HTML/JS skills to create a browser based editor for it - just a web page with some JS to render out UI and store changes back to the JSON. This would make working with the tech tree vastly more accessible IMHO - it would give a very consistent "single source of truth", it would be something AIs and other scripts could readily interact with, and it would also be a big step towards an opportunity to port some of the C++ WZ code over to JS.

At a later date, I'd also like to see things like model definitions (I've no idea of correct terminology) and animation definitions ported over to JS objects as well. For example, oil derricks and sensors could be animated by calling a JS function - this would then mean that animations could be affected by game state without adding loads of cruft in to the game. It would also open possibilities to have more advanced animations for units, for example a transporter that opens a loading ramp to allow units to embark/disembark. And, again, it would make browser-based editors feasible for modding the game.

Imagine, for example, being able to load a body & propulsion model in to the browser using webgl (I've no idea if this is feasible or not) and then place turrets on it visually, possibly even naming them or setting other properties on them such as what sort of weapon/sensor can be used on a particular turret or body/propulsion combination. You could, for example, have multiple turret configs for a body - so for VTOLs you could choose a 2 turret config with a gun under each wing, or a single turret config with heavy weapon under the nose. Just a random idea, but playing with these ideas isn't going to be feasible unless the config gets a whole lot more flexible and also easier to work with at the same time.

One of the problems I think with the current config of the game is that there are files of all different formats strewn all over the place. Not only does that lead to lots of C++ code bloat, but it also requires a fair amount of learning before you can go in and make changes, which may discourage lots of people from getting in to modding. If there was a consistent approach to the config, along with browser based editing, I think we'd see a lot more contributors trying their hand at modding. In some respect that would lead to chaos, but I think it would also help make the WZ community and gameplay even more vibrant and fun.

You are going a bit too far with using WebGL for that, I think.
Normal application with GLView would be enough and more performance efficient (and don't need WebGL loader for model files).

Did anyone say animation?

@Jorzi I was pondering over what more flexible config scripts could enable in terms of animations, and other features relating to models. As I have no idea how all that stuff works, other than drooling over the pics you guys keep uploading of new terrains, turrets and propulsions, etc., I was just throwing a random idea in to the mix. Would be really interested to know more about the challenges you guys face and ponder if any of them could be handled with alternate ways of defining things, possibly via JS.

For me JS should be only capable of triggering specific model animations (there could be list available as property), I'm not sure if animating many objects using JS would be efficient (we need test cases )...

Well, we have a new model format called wzm. It is quite simple and fixes most of the problems with the .pie format. Its most notable feature is that it saves vertex normals and tangents, allowing for smooth shading and tangent space normal mapping.

The current animation system is hardcoded enough not to work at all with the new format. It is also quite inflexible. You either animate by writing rotation and location parameters for each frame into a text file, or you simply export each frame as a separate model and display them in order. Also, things like barrel recoil is hardcoded somewhere else and cannot be edited. This means the current animation system could as well be scrapped instead of trying to make it work with a new model format.

What I really would like is a simple robust keyframe-based animation system.

@Emdek: Yes, I had considered the performance impact also - however, what if a function could be used to define the animation and it's output cached in some basic C++ data structure that's really fast for use in the game engine? I've been experimenting caching of function output in my experiments with mutators, so hopefully I'll find some workable solutions soon.

By having functions define animations, optionally cached (or default cached), much more natural animations could be created without the tedium of manually plugging loads of numbers in to a strange text file (I can't remember what the text files are called, but I found one in my travels and their format gives no real indication of what's supposed to be happening). Using JS functions would provide a more transparent way of "describing" an animation via some mathematical formula, and likely make experimenting with animations much easier (for those that, unlike me, are good at maths). With the output cached, the game engine can use whatever data structure it wants, but for me I feel the big hurdle is defining the animation in a transparent, hackable and maintainable manner in the first place.

Just for my own sake, I'll explain how I came to be even pondering about animations, an area of the game I know nothing about.

I was thinking about how the whole config of the game hangs together. My repeated attempts to decipher the tech tree and tech prereq's were leading mostly to frustration. I eventually started to get to a point where I could identify key research paths, and then started to see patterns in how certain techs affect certain things. This was all done from the perspective of coming up with a data structure that an AI script could understand, so it could make decisions about what to research next based on current game state and so on.

I envisioned a future where each tech was defined as a JSO (javascript object) with various properties like it's name, id, costs, effects and so on. If there was then a repository (just a big array or object to store these tech objects) it would become quite easy to have a number of files like:

research_cannon.js
research_VTOL.js
etc...

Each defining techs applicable to some part of the research path, or some similar aspect of the game. This would make finding and editing techs very easy, it would make adding new techs trivial as well, and it would be very clean way for the game to load the data because it just eval() on each file to create an active JSO that both C++ and JS can interact with.

There would then be a repository of pre-requisites (this idea actually based on Shadow Wolf TJC's recent post about how it works in WZ already.

So that then started me thinking, along with my JS API documentation, what if large chunks of the game could be ported to JS - massively cleaning the codebase in the process? That's discussed more in mutators topic.

That then made me think.. what if we could make everything more consistent. By chance I'd just stumbled on to one of the animation files and my first thoughts were "I have no idea what any of this text means". I think to get more people contributing there needs to be greater clarity in the code and config, and more concise or descriptive ways of doing things.

A lot of the game code and config can be done in a much higher level language, because it's infrequently processed during a game. So there might be a whole bunch of JS for the engine to parse at the start of the game, but it doesn't really matter as that process is actually quite fast anyway in recent JS engines, and the extra clarity of config and game code more than justifies a couple of extra seconds waiting for a game to start.

@Jorzi - just spotted your post, I need to grab food but will respond when I get back.

Caching would be required, I think.
We probably need to get some disk caching infrastructure too (own or use Qt to at least get path to system cache directory).

@Jorzi the only keyframe animation stuff I've ever had exposure to is in Flash (back in the days when Macromedia owned it) and CSS3 (although I've not used it).

Would I be right in thinking that the main benefit is to be able to animate multiple things at once? Say recoil + barrel roll?

Well things that we would animate would probably be, among others:
-choosing what parts of the barrel would recoil and how far (for example, in our cannons we would want only the barrel and not the barrel housing to recoil).
-as you said, we could make the assault gun/cannon spin to the next barrel after firing.
-scavengers and cyborgs, preferably using bone animation
-wheels/tracks spinning (maybe texture only)
-building actions, like factory doors opening

Don't forget about rotating fans.

Ah yes, thank you Emdek

In the JS mutator code I'm writing I've actually got a standard scenario where any object, if configured to do so, can be considered a cargo container that droids (of specific propulsions) can move in or out of. Would be great if droids built at a factory, for example, started in the factory, then the door opens and they drive out. With mutators having them drive out would be trivial to do by adding an initial movement action to their task list, but getting the factory doors to open at the right time would be a bit more tricky, maybe they could work like gates...

In the new wzm format, is it possible to name or somehow reference bits of the model? If so then I imagine that it would be possible to link animations to object actions or states?

Example of what a JS animation script could look like:
I don't know if that's the sort of thing that could be useful, or if there's better ways to do it. However, it's a simple JS object that the C++ code could grab at start of game and cache or convert to some other format for better performance.

Also, the objects could be created programatically - eg. if there was some complex animation where you wanted motion to follow a sort of bezier curve of movement, a bit of JS could be used to create the data in the object during the eventGameInit() event.