[tetrinext] Re: TINT UI and Theme Standard draft -- part 2: theme standard

[Alexander Hvostov <vulture@xxxxxxxxxxxxxx>]

Jared,

Whatever you do, don't make the syntax look like Lisp. EWWWW!

Instead, check out the very cool ISC configuration file syntax (which is
the syntax used for their DHCP and DNS servers, and probably INN).

Regards,

Alex.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM d- s:+ a--- C++++ UL++++ P L+++ E W++ N o-- K- w
O--- M- V- PS+ PE- Y PGP t+ 5 X- R tv+ b DI--- D+
G e-- h++ r--- y
------END GEEK CODE BLOCK------

On Fri, 24 Mar 2000, Jared Johnson wrote:

> 
> okay, i finished dinner. i was going to get fast food, but then i found out 
> that
> I have enough money in my bank account to MAYBE cover the checks i've written,
> so it was ramen noodles tonight, mmmmm.
> 
> a few notes.  most of this was written right after my first post, so if you've
> posted anything about the first post, you'll probably end up posting the same
> thing about this one.  also, i am pretty sure this will have major problems 
> and
> defeciencies.  that's OKAY, let's just fix them and get the thing onto the 
> page
> asap =)  on with the show.
> 
> 
> 
> Theme Standard
> 
> 
> 
> Introduction
> 
> TINT is designed to allow for modification of nearly every aspects of its
> appearance and interaction; thus, themes designed for TINT can range from 
> very simple
> changes to the default to complex themes changing and adding to a great number
> of aspects.  We will talk about Resources, Elements, and Events, and 
> Conditions
> -- what they are and how they are used.
> 
> 
> 
> Resources
> 
> Resources are the content that theme authors may use in their themes. 
> Resources will include the following:
> 
> -Graphics.  Graphical resources include pictures in various image formats
> (which will be determined later) as well as color settings.  Many elements 
> can be set
> to use either images, colors, or to be transparent.  Also, it is at the option
> of the theme author whether to have the image that an element is set to be
> scaled, tiled, or centered onto the element that it is set to.
> 
> -Sounds.  Sounds in TINT can also be stored in various file formats not yet
> determined.  They are pretty much self explanatory, aren't they =)
> 
> -Screen Hacks.  Screen hacks are made possible by SDL.  These can be used to
> create a plethora of fun, effective, or annoying screen effects.  For more
> information, take a look at the screen hacks on the SDL page.
> 
> -Configuration.  This includes things like size and location of panels, and
> anything else that isn't really content, just a setting.
> 
> 
> 
> Elements
> 
> Elements in TINT are the aspects of TINT which can be assigned resources. 
> These include just about everything graphical; the blocks, the field 
> backgrounds,
> the pane borders, the menu elements, etc. -- an element can be re-assigned a
> resource during gameplay, via events and conditions, described below.  If the
> resource is not bound to any event or condition, it is assumed to be "always 
> on".
> 
> 
> 
> Events
> 
> In order to allow theme authors to do just about whatever they want, TINT will
> make use of many events that can be used as "triggers" when bount to a 
> resource
> change defined by the theme author.  An event in TINT will basically be any
> action that the user takes in the program or any change that takes place in 
> the
> game, which is associated with a name and added to the theme standard.  
> Examples of
> an event can be anything from the user placing his mouse over a menu item, to 
> a
> user moving or rotating a piece, to a level advancement, to the exit of the
> program.  Other examples will be outlined further in this document.  A theme 
> author
> has complete control over what he wishes to bind to an event, which means that
> he can do some very pretty as well as some very ugly things.  For instance, 
> the
> theme author can create an SDL screen on the player's background around the
> player's piece which creates a "rippling water" effect, and associate one of 
> these
> for each of the left, right, up, and down piece movements -- creating a very 
> nice
> effect.  On the other hand, the theme author can associate each piece movement
> with a complete change in skins, a strobe light effect, and the playing of a
> star-spangled-banner midi file.  This would probably not be a very nice 
> effect ;)
> 
> 
> 
> Conditions
> 
> Conditions are just that, conditions.  Conditions include things like being
> in-game, being in a particular level, having a particular mode set, whatever. 
> Theme authors can use conditions about the same way that they use events.  
> They
> again have complete control over what they do with this.  You get the picture.
> 
> 
> Example
> 
> Let's say the standard has defined gameplay-pane, entire-window, 
> player-blocks,
> player-background, opponent-blocks, and opponent-background  as elements; it
> has defined game-start, jump-to-level2, jump-to-level3, game-end-won, and
> game-end-lost as events; it has defined in-game-level1, in-game-level2, and
> in-game-level3 as conditions.
> 
> The theme author makes a set of pixmaps for players' and opponents' blocks and
> backgrounds in each of the three levels. as well as for out-of-game.  here is 
> an
> example of a config file (with syntax that is completely off the top of my
> head) that a theme author could use:
> 
> #no condition or event set, so always-on
> #(except when a condition or even overrules us, of course ;)
> (gameplay-pane=screenhack:smoke)
> (sound:tintsound.midi)
> (playerblocks=graphic:player-blocks-outofgame.png)
> (playerbackground=graphic:player-fieldbg-outofgame.png)
> (opponentblocks=graphic:opponent-blocks-outofgame.png)
> (opponentbackground=graphic:opponent-fieldbg-outofgame.png)
> 
> #here comes an event!
> [gamestart]
> (entire-window=screenhack:really_cool_screen_hack_gamestart)
> (sound:gamestart.wav)
> 
> #and then a condiation
> [in-game-level1]
> (playerblocks=graphic:player-blocks-level1.png)
> (playerbackground=graphic:player-fieldbg-level1.png)
> (opponentblocks=graphic:opponent-blocks-level1.png)
> (opponentbackground=graphic:opponent-fieldbg-level1.png)
> (sound:level1.midi)
> 
> #now you get the idea, let's do some more
> [jump-to-level2]
> (entire-window=screenhack:screen_hack_jumpto2)
> (sound:nifty_sound_jumpto2.wav)
> 
> [in-game-level2]
> (playerblocks=graphic:player-blocks-level2.png)
> (playerbackground=graphic:player-fieldbg-level2.png)
> (opponentblocks=graphic:opponent-blocks-level2.png)
> (opponentbackground=graphic:opponent-fieldbg-level2.png)
> (sound:level2music.midi)
> 
> [jump-to-level3]
> (entire-window=screenhack:level3extremelycoolhack)
> (sound:oohlevel3bigdeal.wav)
> 
> [in-game-level3]
> (playblocks=graphic:player-blocks-level3.png)
> (playerbackground=graphic:player-fieldbg-level3.png)
> (opponentblocks=graphic:opponent-blocks-level3.png)
> (opponentbackground=graphic:opponent-fieldbg-level3.png)
> (sound:level3isabigdeal.mp3)
> 
> [game-end-won]
> (sound:woohoo.wav)
> (gameplay-pane=screenhack:cool_fireworks_hack)
> 
> [game-end-lost]
> (sound:darnit.wav)
> (gameplay-pane=screenhack:cool_shattering_glass_hack)
> 
> okee
> 
> signing off.
> 
> -- 
> Jared Johnson
> solomon@xxxxxxxxxxxxx
> 
> Wilner's Observation:
>       All conversations with a potato should be conducted in private.
> 
> -----BEGIN GEEK CODE BLOCK-----
> Version:  3.12
> GCS/C d+(-)>-- s:+ a18 C++++$ UL++++>$ P+>++++ L+++ E--- W+ N+ o? K- w--- !O
> M-- V-- !PS !PE Y PGP- t+ 5-- X R-- tv- b+ DI>+ !D G e>++(>+++) h-- r* 
> y-(>+++)
> ------END GEEK CODE BLOCK------
> 
> 
>