Sign in with
Sign up | Sign in
Your question

A few weeks with Lua, and what I learned from it

Tags:
  • Video Games
Last response: in Video Games
Share
Anonymous
July 12, 2005 5:43:38 PM

Archived from groups: rec.games.roguelike.development (More info?)

After spending far too long tinkering around with my scripted dungeon
generation code, I decided to try making my entire game scriptable in
Lua. These are a few of the things that I've learned from this
experience, and hopefully someone else can learn something new from it.

Firstly, speed concerns are nonexistant. While working on a machine
far older than most dev machines in this group, I found it safe to
conclude that running the main game loop in Lua was fine, with no
noticeable speed concerns.

Secondly, Lua is far easier to work with than I thought originally.
In about three hours time, I was able to whip up all the necessary C++
binding code, as well as write a decent set of graphics, sound, and
input routines to register with Lua. It wasn't beautiful code, but it
compiled, and it worked without flaw.

Next, it was time to learn to fully exploit Lua's power. Right away,
I coded up a simple main loop in "main.lua", and drew out a (very
ugly) map. Up until this point, I was competent enough in Lua to be
functional, but I lacked any real deep understanding, and, more to the
point, had yet to fully understand the full power behind Lua's main
data structure: tables. When I decided to code up a simple main menu,
I (naturally) was forced to use tables to handle it. Wow.
Simplicity, easily readable, and powerful. Beautiful. It was then
that I realized that with Lua, ordinary datafiles are completely
useless. Lua is so fantastic at describing the data in the first
place, that there is no reason to bother parsing ugly datafiles. I
can just run the script, and all the data will load itself into all
the right places. Very nice.

Also handy is the fact that Lua functions are treated as first-class
values. This means, any function can be stored in a variable,
arranged into a table, or whatever. Other languages do this as well,
and some do it just as good, but many languages require kludgey hacks
to achieve this same level of control.

Now, stepping away from the Lua aspect of this project for a moment,
let me address a few more things quickly.

I knew from the start that I wanted my RL to have sound in it. Ever
since I played the sound-enabled DoomRL release, I've realized just
how truly important sound was, even to a "primitive" ASCII or
tile-based game. Most games (that I'm aware of) handle sound in a way
that I find somewhat displeasing. Most games have any creature/object
which makes a sound run the ".wav" themselves, or directly call the
sound handler themselves, which seems likely to cause problems. The
way I'm going about it seems to work rather nicely for me, so far.

What I do is I create a global sound stack. Any creature/object which
makes a sound places their sound effect name on the sound stack, along
with their coordinates on the map. At the end of each turn, the sound
stack is processed, and each sound is then processed, and played using
3-D positional effects based on their coordinates. By storing all of
this info in a single structure, I can track sound for game purposes,
run special checks/filters/etc. on the entire sound stack, without
having to do so for every single sound that gets called by independant
functions. For example, if the player gets deafened, one check is
made at the end of the turn to see if the player is deaf, and then the
entire stack gets emptied, unprocessed. In some other systems, each
sound call would have to check if the player is deaf, resulting in
several unnecessary calls.

Anyways, I've blabbed on enough for now. Take what you will from
this. The last couple weeks have been a real learning experience for
me, and it'd be a shame for nobody else to benefit from this. Anyone
who has any more detailed questions regarding Lua or anything, feel
free to ask. I'm no expert, but I know enough to be helpful.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--

More about : weeks lua learned

July 12, 2005 5:49:11 PM

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> I knew from the start that I wanted my RL to have sound in it. Ever
> since I played the sound-enabled DoomRL release, I've realized just
> how truly important sound was, even to a "primitive" ASCII or
> tile-based game. Most games (that I'm aware of) handle sound in a way
> that I find somewhat displeasing. Most games have any creature/object
> which makes a sound run the ".wav" themselves, or directly call the
> sound handler themselves, which seems likely to cause problems. The
> way I'm going about it seems to work rather nicely for me, so far.
>
> What I do is I create a global sound stack. Any creature/object which
> makes a sound places their sound effect name on the sound stack, along
> with their coordinates on the map. At the end of each turn, the sound
> stack is processed, and each sound is then processed, and played using
> 3-D positional effects based on their coordinates. By storing all of
> this info in a single structure, I can track sound for game purposes,
> run special checks/filters/etc. on the entire sound stack, without
> having to do so for every single sound that gets called by independant
> functions. For example, if the player gets deafened, one check is
> made at the end of the turn to see if the player is deaf, and then the
> entire stack gets emptied, unprocessed. In some other systems, each
> sound call would have to check if the player is deaf, resulting in
> several unnecessary calls.

This is interesting. I use a similar structure - except that the
resulting 'sounds' are simply onscreen messages rather than real
sounds.

How do you produce positional effects???

What do you do when sounds are coming in faster than they can be
played? Do you superimpose them, or cut them off short when the next
sound arrives, or ...?

A.
Anonymous
July 12, 2005 10:08:41 PM

Archived from groups: rec.games.roguelike.development (More info?)

At Tue, 12 Jul 2005 13:43:38 -0400,
Timothy Pruett wrote:

> For example, if the player gets deafened, one check is
> made at the end of the turn to see if the player is deaf, and then the
> entire stack gets emptied, unprocessed. In some other systems, each
> sound call would have to check if the player is deaf, resulting in
> several unnecessary calls.

I think it doesn't matter whether you play sounds or not when the *player*
is deaf... ;) 

--
Radomir `The Sheep' Dopieralski @**@_
(nn) 3 Grin
. . . ..v.vVvVVvVvv.v.. .
Related resources
Anonymous
July 13, 2005 6:44:00 AM

Archived from groups: rec.games.roguelike.development (More info?)

I'm not sure about playing all sounds at the end of the turn. In a
sound effect system I would expect or like:
1) an immediate feedback when the player character or a creature acts.
2) sequential sounds for consecutive events (e.g. war cry, then noise
of sword piercing breastplate, then exclamations and cursing).
3) a very limited "polyphony" of different sounds in order to discern
them, even if by the rules they are simultaneous.
4) something to hear during the player's think time, e.g. uncomfortably
near breathing and shuffling of feet.

Lorenzo Gatti
Anonymous
July 13, 2005 1:31:31 PM

Archived from groups: rec.games.roguelike.development (More info?)

gatti@dsdata.it schrieb:
> I'm not sure about playing all sounds at the end of the turn. In a
> sound effect system I would expect or like:

Since most everything but waiting for player input happens
instantaneously, there's no difference between doing it when it happens
and just queing them up and playing them at once.

If you want there to be sounds for things that don't take up any game
world time, such as traversing the interface, that would be different.

--
Jim Strathmeyer
Anonymous
July 14, 2005 3:47:55 AM

Archived from groups: rec.games.roguelike.development (More info?)

In article <1121247840.507524.179580@g43g2000cwa.googlegroups.com>, gatti@dsdata.it wrote:
>I'm not sure about playing all sounds at the end of the turn. In a
>sound effect system I would expect or like:
[snip]
>4) something to hear during the player's think time, e.g.
uncomfortably
>near breathing and shuffling of feet.

That seems like a bad idea to me. But I'm the kind of person that
immediately looks for the "off" button for the background music on
flash-based websites.

Alan
Anonymous
July 14, 2005 5:33:11 AM

Archived from groups: rec.games.roguelike.development (More info?)

Antoine wrote:
>
> Timothy Pruett wrote:
>
>>I knew from the start that I wanted my RL to have sound in it. Ever
>>since I played the sound-enabled DoomRL release, I've realized just
>>how truly important sound was, even to a "primitive" ASCII or
>>tile-based game. Most games (that I'm aware of) handle sound in a way
>>that I find somewhat displeasing. Most games have any creature/object
>>which makes a sound run the ".wav" themselves, or directly call the
>>sound handler themselves, which seems likely to cause problems. The
>>way I'm going about it seems to work rather nicely for me, so far.
>>
>>What I do is I create a global sound stack. Any creature/object which
>>makes a sound places their sound effect name on the sound stack, along
>>with their coordinates on the map. At the end of each turn, the sound
>>stack is processed, and each sound is then processed, and played using
>>3-D positional effects based on their coordinates. By storing all of
>>this info in a single structure, I can track sound for game purposes,
>>run special checks/filters/etc. on the entire sound stack, without
>>having to do so for every single sound that gets called by independant
>>functions. For example, if the player gets deafened, one check is
>>made at the end of the turn to see if the player is deaf, and then the
>>entire stack gets emptied, unprocessed. In some other systems, each
>>sound call would have to check if the player is deaf, resulting in
>>several unnecessary calls.
>
>
> This is interesting. I use a similar structure - except that the
> resulting 'sounds' are simply onscreen messages rather than real
> sounds.
>
> How do you produce positional effects???

SDL_mixer takes care of most of that work for me. A simple function
allows me to set the angle of the sound effect (direction from the
player) and the distance of the sound. The end result is rather
appealing. A dragon roaring 100 feet to the south east will sound
like a dragon roaring 100 feet to the south east. Anyone with nice
surround sound speakers, or (like me) nice Bose headphones get a
delightful treat. In the above example, the roar would sound loudest
in the right speaker, and louder towards the back. An orcish warcry
from straight ahead, only 10 feet away, sounds loud and straight forward.

And, luckily for me, this is all fairly simple. I just do a quick
calculation to determine the angle between the player and the object,
and then I figure the distance, plug them into to my SDL_mixer wrapper
function, and I'm set.

> What do you do when sounds are coming in faster than they can be
> played? Do you superimpose them, or cut them off short when the next
> sound arrives, or ...?

They get superimposed. Just like real sounds do. Cutting them off is
far too artificial and just not worth it. The way I see it, if 10
loud sounds are blasting through at once, it _should_ be loud and
confusing. It enhances the mood, and can make battles noisy, frantic,
and occassionally, somewhat disorienting. I like it that way. And,
since my target audience is me, any other player is more than free to
change that for themselves, or turn sounds off.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
July 14, 2005 12:10:59 PM

Archived from groups: rec.games.roguelike.development (More info?)

At Thu, 14 Jul 2005 01:33:11 -0400,
Timothy Pruett wrote:

> They get superimposed. Just like real sounds do. Cutting them off is
> far too artificial and just not worth it. The way I see it, if 10
> loud sounds are blasting through at once, it _should_ be loud and
> confusing. It enhances the mood, and can make battles noisy, frantic,
> and occassionally, somewhat disorienting. I like it that way. And,
> since my target audience is me, any other player is more than free to
> change that for themselves, or turn sounds off.

Do you handle duplicates in any special way?
i.e. some monsters will surely share the same 'pain' sound. It's
quite possible that you hit several of them in one turn (ie. with some
kind of area effect) -- then there will be several identical samples to
play.

Do you remove the duplicates, shift them in time a little so that they
sound as chorus or simple leave them as they are, only making the sound
louder?


--
Radomir `The Sheep' Dopieralski @**@_
(--) 3 ..zzZZ
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 14, 2005 12:11:00 PM

Archived from groups: rec.games.roguelike.development (More info?)

The Sheep wrote:
> At Thu, 14 Jul 2005 01:33:11 -0400,
> Timothy Pruett wrote:
>
>
>>They get superimposed. Just like real sounds do. Cutting them off is
>>far too artificial and just not worth it. The way I see it, if 10
>>loud sounds are blasting through at once, it _should_ be loud and
>>confusing. It enhances the mood, and can make battles noisy, frantic,
>>and occassionally, somewhat disorienting. I like it that way. And,
>>since my target audience is me, any other player is more than free to
>>change that for themselves, or turn sounds off.
>
>
> Do you handle duplicates in any special way?
> i.e. some monsters will surely share the same 'pain' sound. It's
> quite possible that you hit several of them in one turn (ie. with some
> kind of area effect) -- then there will be several identical samples to
> play.
>
> Do you remove the duplicates, shift them in time a little so that they
> sound as chorus or simple leave them as they are, only making the sound
> louder?

Shift. Since all sounds are read from the stack, all at once, it's
very easy to spot duplicates. When it's time to play the sounds, I
shift all duplicates +/- rand(50,250) milliseconds. Such a minor
shift is all that is typically necessary. I'll likely tweak the exact
range of randomness later, but for now those values are working for me.

Originally I had tried to go with letting duplicates overlap, and play
at a louder volume, but it proved to be too difficult to work right.
Since _all_ sounds are played using the positional sound function,
adjusting the volume manually frequently ruins the positional effect.
And even when it did work right, it sounded too wierd and fake, and
just rubbed me the wrong way.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
August 16, 2005 6:02:39 PM

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> What I do is I create a global sound stack. Any creature/object which
> makes a sound places their sound effect name on the sound stack, along
> with their coordinates on the map. At the end of each turn, the sound
> stack is processed, and each sound is then processed, and played using
> 3-D positional effects based on their coordinates. By storing all of
> this info in a single structure, I can track sound for game purposes,
> run special checks/filters/etc. on the entire sound stack, without
> having to do so for every single sound that gets called by independant
> functions. For example, if the player gets deafened, one check is made
> at the end of the turn to see if the player is deaf, and then the entire
> stack gets emptied, unprocessed. In some other systems, each sound call
> would have to check if the player is deaf, resulting in several
> unnecessary calls.

You DON'T want it this way. I tried it in DoomRL -- the effect was that
there was a cacophony of growls/attacks/smashes each turn -- because
they all played at EXACTLY the same time. Let the sounds play as the
processor needs them -- it may be milliseconds between, but it DOES make
a difference. Also if you use animations (like Explosions in DoomRL)
then it helps much to play sounds on the fly.

Another problem is the [more] prompt -- you would have to empty the
stack on it.

But generally -- a sound stack is a BAD idea.
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Come on, Kornel. 11 years and no binary? And it's not
vapourware?" -- Mike Blackney
!