The purpose of TROIACS is to give you a stable, fun platform to develop your adventure games.

TROIACS will allow virtually anything imaginable to happen on your screen, while letting you easily put things together. It is not half way through but it is already so flexible you could almost make a platform game or a shoot'em up game with it! (It will indeed be a possibility when it is finished).

But let's stay focused on adventures. Everything in Troiacs is an animation. An animation doesn't need to move! It can have only one frame. So the background is also an animation. What does this mean? That every object on the screen and in memory, visible or not, is really just the same thing.

Let's see how an animation works. An animation contains frames. Frames are just bitmaps, loaded when the player enters the scene. They contain no information on where or how they need to be drawn. An animation also contains an AnimScript (don't ask me how I come up with such fancy names). Attention: an animscript is not a "script" of commands but of drawing information. An animscript contains exact instructions on how to draw the animation, taking frames as starting points, and doing crazy things to them. Every step of an animscript is an animstage (explained later).

An animation also contains scripts and variables, but it isn't the only place where these are found. Scripts inside an animation allow you to respond to events no matter what the current animstage is. For example, you want your character to be able to TAKE the parrot no matter which frame of the parrot animation it happens to be in. You put an event handler in the animation script. Well what happens if your animation has a few frames in which the parrot is flying and the player can't reach it? You now use the script that is contained in (linked to from) the animstage (whether these replace, follow or precede the animation script is your option, in this case we'd choose "REPLACE"). Most parameters will be duplicate, global, animation-wise and animstage-wise so that you can easily make easy stuff but can also have very specific behaviours associated with all of your objects.

Let's go back to the animstage for a while. An animstage represent a single interval or redraw state of an animation. Each animstage contains a displaychain structure (again these fancy names). A displaychain structure is what really decides how to draw which frames. For example, say you want to take frame 1 and blend it with frame 2, then scale it by a factor (this is an expression so you can use any variable to control this). You create 3 display operations inside the displaychain. 1) take frame 1 and 2 and perform a FADE transform with factor 50%. 2) take the resulting frame, and scale it by any x,y. 3) blit on screen. Now if you don't need any special effects, all anim stages initialize their displaychain with only one operation and default to simply "blit on screen". These operations include all conceivable directx transforms (water, ripple, paint) including the metacreations transforms (cracked by me heh heh) that come with directx media (see them here). Check out the demo - coming soon - to see what this means. Transitions between scenes will be REALLY cool although I just found out they won't work under windows NT. Troiacs will then have a switch to detech windows NT and not attempt to use transforms. By the time Troiacs is really advanced Windows 2000 should be on most pcs though.

Animstages contain other variables, such as x and y position which are expressions and offsets/replacements (you choose) to the animscript x and y position (the overall position for all stages) and default to "offset/0/0". This way you can fine tune your character walking frames you digitized and rotoscoped with a quickcam and seem to move all over the place...

1) Cut scenes will only be scenes in which there is no command interface, and in which a script is controlling all characters' movement and speech and timings.

2) The interface itself will be a series of animations that have events associated to them. Buttons can now be animated ?!?!?! I hope I am not putting too much power in the hands of the masses here ;) ...

A simple button will be an animation with x and y positions, two frames (normal and pushed), and events associated with the click that alternate the button state, and set a variable (ex. currentcommand = 'take'). Now whenever you click on something (an animation of course), if this animation wants it can detect the click, detect the take command, and run a script to perform an action. For example have the character move to a spot, make it TAKE, and add an item to the inventory. Here emerge two needs: 1) scripts must be able to call other scripts, especially animations must be able to call scripts that are global either to the scene or to the animation; this prevents you from typing the same thing 1000 times. 2) Animations must contain SEVERAL animscripts. Why? This makes everything simpler, your character has 1 animscript for walk left, 1 for walk up, 1 for walk right... they cycle automatically, they already do as of today (although you can obviously stop them at one frame with a script command inside that animstage), so you only need to say PARROTANIM->SelectAnimscript(dance) for the parrot to start dancing, and you avoid having one animation object for the parrot walking and one for flying and one for wiping its ass etc.... Also some animations occur all the time such as the interface, so there must be a way of "including" globally created animations into scenes.

Backgrounds will also be an animation, with only one frame and one animstage. The animstage will have a simple nontransparent blit (for speed). It will have a script too, to set x and y position. This can make a larger-than-screen bitmap easily scroll back and forth with the character and the scrolling logic remains a property of the background animation object.

Tools for automating the creation process will be made along the way, such as simple utilities to position sprites on the screen, animation preview programs, a testing and debugging version of the runtime module to trace variables etc.

A quick overview of TROIACS structures: