Collectible Card Game Headquarters

Thanks to everyone for kind comments, glad it works fine for you all!

Yeah, Shandalar sounds do sound appropriate there and have a serious nostalgic feeling to them. It's up to the team what sound packages to decide to redistribute, really, so what does everyone think? There can be several packages, too - I mean, we could also come up with our own free one, as well as at least recommend the Shandalar ones (maybe with time I'll write a convertor utility which will import Shandalar sounds into Forge.

- Agetian

While it's definitely cool and nostalgic to use Shandalar sounds, I think there's something to be said about having our own look, feel, and sound. If users want to use the Shandalar sounds that's cool, we can show them exactly what they need to do that.

friarsol wrote:While it's definitely cool and nostalgic to use Shandalar sounds, I think there's something to be said about having our own look, feel, and sound. If users want to use the Shandalar sounds that's cool, we can show them exactly what they need to do that.

Yep, exactly, I can write a converter or something like that that will be used to easily import Shandalar sounds if necessary. I also believe the cardforge.org sound set should be something original.

Diogenes wrote:Anyway, I was just going to say that it might be worth sticking with the opening coin-flip instead of moving back to a die-roll, in case that came up. I happened to find a stack of tokens from the WotC game center with some of my old stuff, and while there are plenty of mtg themed life counters that can be used as d20s, I don't think there's ever been an official coin. Anyway, I'm not a scanning pro (and both my scanner and multifunction are boxed up right now) so if anyone thinks it would be nifty to have a themed coin image, I'm willing to mail one / drive one over (don't know how common they are anymore, but I wasn't able to find a good image online.)

This sounds like a great idea! Would be nice to have that!

P.S. A little but important question: I'm looking for the place in the code that could be used to hook up the card activation sounds. In particular, I'm interested in the code that would fire when a card is played (e.g. the creature card goes on the battlefield and becomes a creature, an instant takes its effect, a sorcery takes its effect, etc.), and so far I haven't been very successful. Can anyone please tell me where to look for that? I'm willing to implement an effect playback based on what type/color of card is played. Thanks in advance!

- Agetian

Agetian wrote:P.S. A little but important question: I'm looking for the place in the code that could be used to hook up the card activation sounds. In particular, I'm interested in the code that would fire when a card is played (e.g. the creature card goes on the battlefield and becomes a creature, an instant takes its effect, a sorcery takes its effect, etc.), and so far I haven't been very successful. Can anyone please tell me where to look for that? I'm willing to implement an effect playback based on what type/color of card is played. Thanks in advance!

I'd imagine these things all happen in MagicStack.resolveStack(). Perhaps you can find useful spots by looking at the callers of GameLog.add()

Oh, I'll check that one out, thanks for the tip!

- Agetian

OK, I committed more implementations of sounds to the SVN. Here are the working ones:

Artifact - an artifact is played from hand.
ArtifactCreature - an artifact creature is played from hand.
BlackLand - a land with the B mana ability is played from hand.
BlueLand - a land with the U mana ability is played from hand.
Creature - a creature is played from hand.
Enchantment - an enchantment is played from hand.
Instant - an instant is played from hand.
Sorcery - a sorcery is played from hand.
GreenLand - a land with the G mana ability is played from hand.
OtherLand - a land with no color mana abilities is played from hand.
Planeswalker - a planeswalker is played from hand.
Poison - a player receives a poison counter.
RedLand - a land with the R mana ability is played from hand.
WhiteLand - a land with the W mana ability is played from hand.

The following sounds are added to the enum but are currently not linked to the code because I haven't figured out where they should go (your help is welcome):

Counter - a counter is added/removed (could potentially be split into two different sounds).
Damage - damage is dealt to the creature.
Discard - a card is discarded from hand.
LifeLoss - a player loses life due to damage.
Regen - a regen ability is activated.
Sacrifice - a creature is sacrificed on the battlefield.

Enjoy!
- Agetian

A small note on placing calls to sound system.

It's not a good idea to call sound playback from depths of magic stack or game action classes, because sooner or later these classes will change into multiplayer server, and sound calls will have to be removed from there.

What I suggest - core clases should only notify their listeners of some events that have happened.
Meanwhile it will be listener's responsibility to choose a right sound and play it. (as well as draw card animations, update hand or battlefield views and perform similiar things).

Max mtg wrote:A small note on placing calls to sound system.

It's not a good idea to call sound playback from depths of magic stack or game action classes, because sooner or later these classes will change into multiplayer server, and sound calls will have to be removed from there.

What I suggest - core clases should only notify their listeners of some events that have happened.
Meanwhile it will be listener's responsibility to choose a right sound and play it. (as well as draw card animations, update hand or battlefield views and perform similiar things).

Sounds like a good suggestion, but I have no idea how to implement that. Can you assist with that or at least tell me exactly what to do?

In particular, I don't know how to:
1. Convert the sound system to an observer-type entity that would overlook other events in Forge.
2. Add the new observer to the all the current events and make sure it's notified of all the various events that may generate sound (especially given how many different kinds of those there are).
3. Discriminate between the different events that may happen (e.g. I can see GameLog.add notifying its observers of changes, but I believe that notification does not actually differentiate between the various types of entries that go on the log, because no parameter is passed in updateObservers (and I don't think it can be), while that's exactly what the sound system is most interested in; same for MagicStack.resolveStack - I don't see the code that would listen for that event to happen right now if there is such a code, and even if there was, I don't know how to make it pass the necessary parameter to its listener, etc.).

I'd probably need as much help with this aspect of Forge coding as possible - I haven't touched observers much in the past (except in some relatively simple textbook examples and such), and moreover, my experience with the event system in Forge is even more limited than my experience with observers in general.

- Agetian

The next day I'll be busy converting quest start screen and checking that unlockable sets mode.
After that will be able to participate.

GameLog should be just one of subscribers to events happening in game.
However, once implemented that mechanism of game event observers will make us closer to multiplayer. Because all the data a remote client would need to learn about other players' actions will pass through the bus we are about to implement.

And an example: imagine there are some 10 creatures on table, and then Damnation! So if there's no listener to filter events on SoundSystem side (just direct calls to play-sound-method), won't it result in 10 death sounds played at a time?

Max mtg wrote:The next day I'll be busy converting quest start screen and checking that unlockable sets mode.
After that will be able to participate.

GameLog should be just one of subscribers to events happening in game.
However, once implemented that mechanism of game event observers will make us closer to multiplayer. Because all the data a remote client would need to learn about other players' actions will pass through the bus we are about to implement.

Sure thing, I tried to think it over and imagine how it could be done but couldn't come up with anything constructive, so... your participation and help would be welcome! Thanks!

And yeah, you're right, several sounds would play at once in that scenario you mentioned, and I have no idea how to make it work otherwise. Like I said, as of right now, I don't see any connection between the updateObservers call and the exact nature of the event that triggered it, so whatever is listening to that is probably utilizing some rather convoluted methodology to extract the information about what exactly had happened. Moreover, since you have a particular implementation in mind that is multiplayer-aware and that is not currently a part of the codebase, I think that whetever I do (even if I go in the generally right direction) might actually go against or conflict with your upcoming implementation. For these reasons, I'd probably rather not implement any global system like that without knowing exactly where I'm going with it (which I don't), so I'll just wait for you to join in.

P.S. I think that the biggest part of my problem with understanding what to do boils down to "how should the other parts of the game notify the Sound System of the event that had happened without directly calling one of its methods in one way or another?"

- Agetian

By the way, as a little follow-up to my previous message, maybe there's just something very simple I just don't get? I mean, would there be any principal difference if I replace the following:

Code: Select all

Sounds.mySound.play();


with this (abstract imaginary code):

Code: Select all

SoundSystem.notify(new SoundEvent(SOUND_EVENT_MYSOUND, card, sa));


and then let SoundSystem.notify filter the event and call Sounds.mySound.play()?
Also, won't that lead to problems with creating multiple SoundEvents on every notification?

Anyway, if this is what's desired, I can do it on my own (I think xD), if it's something more complicated related to a tighter integration with the Observer system of events currently set up in Forge, I'd probably rather wait for Max to join in

- Agetian

Nope, magic stack notifies something unrelated to soundsystem, like an event feed. Into that feed goes just an event with some parameters.

As sound system (among several other subscribers) receives that event, it does decide which sound to play as a reaction on that event. So magic stack does not know which sound that will be and holds no reference to client-side code or resources it would use.

I also want GameLog to get events from there.

Max mtg wrote:Nope, magic stack notifies something unrelated to soundsystem, like an event feed. Into that feed goes just an event with some parameters.

As sound system (among several other subscribers) receives that event, it does decide which sound to play as a reaction on that event. So magic stack does not know which sound that will be and holds no reference to client-side code or resources it would use.

I also want GameLog to get events from there.

Is there any code related to that right now that would demonstrate how that works? I can't find any code that would function as an event feed, and/or a good example of how this notification system is currently set up (a specific example: <this> puts a X event into the event pool, and <that> gets that X even from the pool and processes it)... If it doesn't currently exist in Forge, then I'm afraid I can't really link anything to it yet. if that's the case, I suggest that I just mark the current calls to Sounds.<...>.play() with a TODO mark stating that those would need to later be reorganized into the framework of event processing, and as soon as you're able to (in a few days or whenever), you can join in and help out with it. Thanks!

- Agetian

There is none in Forge, I'm afraid.

The current observers that are set up in Match UI and when a new game starts are
1. peer-to-peer and hold a direct reference to an object being watched. So when update event triggers they request the new object state from that reference and redraw their views
2. trigger-only. There comes only a notification that something has changed, wihtout any details of what has changed and how.

The what I am suggesting is Message Bus Pattern
http://stackoverflow.com/questions/3987 ... their-code

My point is that such approach is somewhat better than a lot of peer-to-peer observer links, because you may send an event from this bus over network, while you can't send an update() call (especially when the callee requests a whole state of object that originated the event)


I think you may proceed as you did for the next few days until beta, but be ready to change (or to discover how your code has changed) when someone (probably me) makes that bus implementation (after beta of course)

I visited the site that Sol found and set up an account. I found a shuffling sound that I liked. It was about 150 k in size which I felt was too large.

I then found the freeware sound app that I used several years ago during the original sound system was added to forge. I was able to reduce the shuffling sound to about 25 k and I think that it still sounds OK.