TGB Future? d6tools

Recently, Melv May asked what would be the future of TGB.
I may have one response about that, with what I call the d6tools.
d6tools is a series of tools designed with modularity in mind, each one is independent from each other, and could be plugged and unplugged at will into any ongoing TGB project.
The objective of the d6tools is clear, being able to quickly prototype games in record times, without having to go out of the builder at all.

Right now, there's 3 of them, beta parts of the now defunct IceWolf project others are still in construction phase. I've not yet finished, but I want to see if there's interest. And I'll decide what to do next.

d6loader:
d6loader manage the ingame load-unload of imagemaps automatically on a level basis (it unload unnecessary image and load necessary ones by looking directly into the .t2d files).

It's simple : you exec the script, and you have a loading management for every levels (if you have changing animation and such, you'll have to notice d6loader in a specific file of what classes or name of objects needs to load specific imagemaps that are not already in the levels).

This get completely out of the way the worries about ram consumption and loading times (it optimize the loadings by not unloading images that are on the next level).

You don't have to ever think about it when making your game. You plug it in, it'll simply works.

(the best example being the IceWolf demo, it greatly manage the ram consumption and loading times even with all these big textures everywhere)

d6sound:
You want one-liner spatial sounds? you get it.
D6sounds get out of the way profiles and channels. You just type "playsfx("soundfile");" and it plays the sound. If you want an object to emit a spatial sound, you type myobject.playsfx("soundsfile") and it play a sound that follow the object. Off course, the function also let you decide the volume of the sound, if it loops or not, streamed or not, etc.

For better performances, you can preload sounds with a one liner too "preloadsound("mysound")", and it will detect and load the preloaded sound automatically when you're playing "playsfx("mysound")", gaining extra process time as the play function wont have to create a profile in realtime (but it's only if your game is really performance hungry, if not you won't see a big difference).

Plus, d6sound automatically take care of most of the OpenAL issues you may encounter without it (at least all the ones I had during the development of IceWolf).

You play the sound, it works. Simple.

(IceWolf use also an early version in its demo, unfortunately I didn't took great advantage of the spatial sounds at the time, the ambient sounds are a little too quiet to be noticeable, but it's in there)

d6event:
The most important of them all. It make a significant speed up everywhere you use it.


It allows you to write code inside a sceneobject, allowing you to write events that happens only in a map, like cutscenes and dialogues. Those who are used to RPG maker may understand better how to use it.
The code inside is reinterpreted into a linear timeframe, allowing a greater cutscenes control, with "wait" commands and build-in dialogues boxes.

But not only cutscenes, it allows you to improvise interactivity while designing a level.
You need this box to explode but you don't feel taking the time to make an exploding box class or such for just 2 or 3 boxes? Then just open the d6event editor in the builder and tell right away to this box to explode when it is in contact of a bullet, and copy past the box to any number you need. Allowing for super fast and unique prototyping.

"Fast Prototyping? But how is this different from behaviors?"
While behaviors are great for creating cross-classes functions, it doesn't improve the workflow of quick prototyping, and for a good reason: each behavior is a predefined condition with a predefined (set of) reaction(s). It greatly limits what we can do with it.

Here's a concrete example:
-If I want a crate to jump when it's in contact with my player (or any other idea that is not in the existing behaviors), obviously there's no forcefully a behavior that does precisely what I want, and I obviously am forced to go down to the creation of a behavior by myself. I must create a new document in my game directory, deal with the behaviors specificities while writing all the code myself from another program than TGB in a CS file... It pretty much result as doing the same as scripting without behavior.
Behaviors didn't really saved me any time for my improvised jumping crate.
-In the other hand, with d6event, all I have to do, is selecting the object, press space to bring up d6event, select the condition, write right away the reaction I want in torquescript, click ok, it's done.

Basically, behaviors are great for doing the same things hundreds of times and across multiple classes of objects, but d6event is better for quickly trying new unique things (which is the very purpose of prototyping, which is really important for indies).


That's a lot of text here, and the quality of my English might be confusing, but hopefully you got the idea.
It's all about getting directly into making a game, and doing it more efficiently, instead of taking all your time managing framework stuff.

Does these modules seems useful to you? ^^'