glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] sound events


From: Fernando J. Rodríguez (Herr Groucho)
Subject: Re: [glob2-devel] sound events
Date: Tue, 10 Jan 2006 19:55:52 -0300
User-agent: KMail/1.7.2

El Mar 10 Ene 2006 06:30, Stéphane Magnenat escribió:
> Fernando J. Rodríguez (Herr Groucho) wrote:
> > El Lun 09 Ene 2006 05:51, Nuage escribió:
> > What about adding sound events triggered when a building or unit
> > is selected (different sounds depending on the state of the
> > building or unit selected), when GUI elements are used, when
> > units do something (harvesting, attacks, magic attacks, etc.),
> > when buildings do something (defense tower shooting a stone,
> > upgrades, destructions, etc.)?
> >
> > It would add some ambieance to the game...
>
> Well, some years ago we decided against adding sound because the
> music is already action dependant, and so sound would tend to
> disturb it/make noise.

I had already read that in the lists archives, but nevertheless let me 
tell you that the action-dependant musis is overrated. Sure: it was a 
nice surprise the first time I played the game, to listen to a 
changing music when my units engaged in combat, but that is all about 
it. Only two contexts for background music, and it would be hard to 
come up with a few more, or even confusing, as units may be doing 
different things in different areas of the map at the same time, and 
there could only be one background music played at a time. Only major 
"states" or phases of the gameplay would deserve their own background 
music.

On the other hand, short and distinctive sounds tied to some GUI 
actions or game elements provide better feedback, which is useful to 
learn quicker to play the game and to play more effectively.
Consider my personal experience in this area:
When I was playing the tutorial set of maps, I had a hard time 
figuring out that the construction site images displayed where I 
wanted a building, didn't necessarily mean that any building activity 
was taking place at all. I had to learn to watch at the small squares 
indicating the number of units working on that building-to-be, or to 
select the construction site and look at the "Working n/m" indication 
on the side bar.

It was also not obvious to me at first that a building under upgrade 
ceases to serve its function while it is being upgraded.

Now, how "short and distinctive sounds tied to some GUI actions or 
game elements" help this?
If a constructing sound/noise was played whenever I clicked a 
constuction site which was actively being worked on, and no sound at 
all be played when no construction is taking place, then the player 
could intuitively know what is going on with that building.

Also, if when a building is performing its function (an inn feeding 
units, a racetrack training units for speed, etc.) it made some 
sound/noise when selected, people would know that it is really 
working, much earlier than when they came to discover that sky-blue 
bar at the side of the map that indicates how many units are inside a 
building and how much time it is left until they leave.

Done properly, sounds events would add usability and playability to 
the game.

Finally, I consider background music as such: background, and I 
wouldn't mind if some short distinctive sound effects conveying more 
gameplay information and feedback disturbs it (but it shouldn't), 
specially as the music tends to get repetitive, in spite of it being 
well composed.


> Now if someone produces clean, nice and 
> proper sound, this can be reconsidered.

I would have supposed that the hooks in the code to trigger said 
sounds events would have to be in place before, so musicians/sound 
authors have something to play with.
But anyway, let's see if someone interested in this can bring up a 
proof-of-concept set of sounds so the reconsiderations can take 
place.

Thank you for reading so far.

-- 
Herr Groucho

ID Jabber: address@hidden
Señal distintiva: LU5MJR - 144,550 MHz FM.
Clave pública GPG: hkp://pks.lugmen.org.ar
Fingerprint GPG: B7BD 0FC7 D9A2 66F3 4EFC  45EE 7DE2 3932 597B 6354




reply via email to

[Prev in Thread] Current Thread [Next in Thread]