|
I read that events in IEventTarget shouldn't have return values. So, i'm wondering how i should think about situations like PlaySound("X") where i need to keep track of the channel used by this sound to be able to change it while its playing. Normally i'd do Channel channel = PlaySound("X") but if i'm not allowed to use return values, how would i go about catching info generated by events that i need? The whole idea of the event target is to not know who takes care of the events so i wouldn't want any dependencies on any other classes where i could get LastSoundPlayed() or similar either. Hmm i guess i could send the object wanting the resulting channel with the event and the event handler connects the channel with the object. Does feel right either. |
Submitted by SolidBenny
Tue, 09/01/2009 - 20:48
|
is PlaySound really part of IEventTarget?
In my games a function like PlaySound() would get called by an IEventTarget method implementation, for example:
void PlayController::asteroidHit()
{
Channel channel = PlaySound("X");
}
As sound is part of "visualisation" I might argue that this would be a bad choice for inclusion in IEventTarget. Does the Model care about sound?
/johno
"you can't stop the change"
I started thinking in those
I started thinking in those terms too. Playsound as an event is probably too low-level and that idea itself is probably what causes the problem. The actual event that GENERATED the need for playing a sound is what should be the event.
I think some old code is clouding my judgement here.
In my gamecontroller i have an effectmanager that stores a bunch of particlesystem instances (should maybe be an effect controller?). in a classic manner each particle system has a fixed amount of particles. in a not-so-classic manner the particlesystem has a list of "behaviours" which controls what to do with a particle each frame.
this is a base class never used by itself. each particlesystem used in the game inherit from the particlesystem and override functions for adding behaviours and creating, emitting and removing the particles. this is currently where sounds are played. when particles are emitted and removed from the world i need the channel to stop the sound.
I think i need some help cleaning up this
I have some thoughts though..
The actual state data isn't in the model at all for the particlesystems. that should probably be moved there and i should just keep the logic for keeping track of the systems in the controller.
creation and removal of particles should maybe be the events instead which the gamecontroller takes care of. I think i still need to store the channel in the particle so I know which channel to stop when a particle is removed however the controller could set it on the particle when it gets a spawnevent.
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
Particle systems as "eye candy"
I would argue that the whole concept of a particle system, of course assuming that it has no real affect on actual gameplay, is something that is only part of the visualization.
As a result, any state required for those things should not be in the Model at all.
In Astro-Creeps, IEventTarget implementations in PlayController (the controller that actually implements IEventTarget on the "receiving end") will spawn various particle effects like space dust, explosions, and lasers, as well as playing sounds.
In my mind all of this stuff is logically View stuff that the Controller is "controlling".
Again; "does the Model care about this stuff?"... I would say no in this case.
Remember, you don't have to be purist about keeping all state / memory in Model; I think this is wrong. You are "allowed" to have state / memory elsewhere. It's just that you don't want to be duplicating state in View or Controller that you already have in Model.
I realize that a lot of this separation seems like overkill unless you actually have multiple Controllers that need to present the Model in different ways. I promise to exemplify this in my upcoming reference game!
/johno
"you can't stop the change"
Gameplay-changing particlesystems
you're right and i should move the eye-candy systems to view because they don't require any control after they're played, however i do use particlesystems that affect gameplay. for example player- and enemyshots so these need to be treated differently. there probably will exist even more systems where sound and collisions must be monitored and changed during their lifetime. at least these must be controlled in the controller.
I'm also starting to think that the question "does the model care?" doesn't to the trick for me. What is the model and what would cause it to care?
So far Model to me only means "here's where you only store data about stuff and don't put things like drawing and soundplaying". I don't think i'm qualified enough to answer the Question based on that
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
Ok I see
I think I understand what's going on.
I suspect that the fact that your player and enemy shots are indeed particles is sort of legacy and a result of over-generalization. The old "I can keep everything in the same list" thing. Am I right?
Would it be possible for you to extract those things from your particle hierarchy and put them somewhere else (in the Model)? If you can find a logical difference between other things that are currently particles (things that are only eye-candy) and things like shots that indeed do affect gameplay, then you have won something.
For the sake of example, Astro-Creeps has a class called Bullet that handles both the orange and the blue bullets (normal and bounce), and while those could be considered particles the are part of the model and separate from for example the class Explosion which is part of View.
On the visualization side both Bullet and Explosion are however rendered very similarly (using Animation objects).
The big difference is that in my case Bullets interact with other objects (Ship, Asteroid) and affect gameplay that way, while Explosion doesn't interact with anything.
/johno
"you can't stop the change"
eye-candy vs weapons
The weapon particle systems and the view particle systems use the same base class because i noticed their base functionality aren't very different (they both utilize particles that move according to different behaviours).
They weren't in the same place as the fire-and-forget effects either. They were in the effect manager and the weapon systems were in the player/enemy objects. There's almost no additional code for the weapon systems as opposed to the regular particle systems at the moment. There are minor differences how they are used on a higher level though (like sound and collision handling) but it felt stupid to not build on the same base.
Weapons will of course need additional data later like weapontype, damage, fire rate, spread and so on.. i just hardcoded these things for the first iteration. Both systems still need an amount of particles that can be sent away with certain properties and behaviour and I think they can be programmed the same way.
Perhaps i can split it up somehow anyway so that stuff like sound playing and collision management float to the surface so to speak and is handled in the controller more nicely.
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
My two cents..
Your are both much more experienced than I am, so what I say is probably not going to matter much but I still want to speak up a little.
I get the feeling you are stuck in some kind of "OO"-trap.
You inherit stuff because they share some behavior, but in the end they are not used the same, and you end up with a mental crisis.
I would say, think more C and less C++. Extract the behaviors into functions with fitting names, then implement your types using no inheritance and instead utilizing your behavior functions for all the shared logic.
I get the feeling you have accidentally locked yourself into a structure that does not exist.
No harm in joining the
No harm in joining the discussion
I inherit stuff because their base functionality is exactly the same. What is different is how the subclasses are used, and I realised that those have been placed and used badly. I still think reusing that base class is the right thing to do but i need to separate the subclasses into viewstuff and gameplaystuff more clearly.
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
Post new comment