• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ankhd

Is this a case for smart pointer usage or is my design wrong,help needed.

12 posts in this topic

Hello there.
What I have so far is a class that holds a vector<Psystem*> of all the different particle systems that can be used.
It also has a vector<cActiveParticleData> when a Unit fires it's weapon it can add to this list.(Renders and processed list)
This is where my problem is.

Should I give the unit a index to the element in vector<cActiveParticleData> and let the unit update this data(no smart ptr needed in this case).
but the particle may end and then the particle system will remove it from the list needs to tell the unit about it.???

or
should cActiveParticleData have a smart pointer to the unit and let the particle manager use this pointer to get the
position data for the emitter.(unit may die before it gets here but)

Or
none of the above;
I'm asking because I have not yet used any smart pointers.
maybe I'm just making a excuse to use them lol.
I looked into
std::shared_ptr

weak_ptr


here,

0

Share this post


Link to post
Share on other sites
I would expect that particles are completely self contained. That is once they are spawned they would not need to reference the Unit again in its lifetime. For instance if the unit fired, it would spawn a particle in the particle system with its position and the particle system would manage it completely after it was initially spawned.

Why does the particle need a reference to the Unit again? What kind of data do you need from the Unit?
0

Share this post


Link to post
Share on other sites
The unit can walk and shoot, rockets move through the air. Can't keep adding a new particle each time a unit move. The emitter needs to move with the unit dies it not.
0

Share this post


Link to post
Share on other sites
Don't create a particle every time it moves, no, but you could create one randomly on movement. The particle then controls it's own movement and animates itself (if so called for) until it's lifetime expires, at which time it is destroyed. All of this management should be done in the particle manager class, with a check done to see if a particle is still alive and needs to be removed in the game's code, i.e.

[source lang="cpp"]for(auto particle : particles)
{
if( particle.isDead() )
//erase particle code here
else
particle.update();
}[/source] Edited by sednihp
-1

Share this post


Link to post
Share on other sites
Sednihp is right you should not have the unit controlling the particle but the particle system. Once it is spawned the particle should not need the the emitter at all. This is the best way to implement it and how professional particle systems work.
0

Share this post


Link to post
Share on other sites
what Im talking about is say the unit is moving and shooting the emitter will need to follow the units weapons position.


the particle system will control all of the particles from its current emitters wold pos, but this world position will need to change
may be not so for a muzzle flash because the muzzle flash is quick just a flash, But for say a rocket its life time is when the
rocket hits something, so dueing this time the emitter will need to move hey
/
- --
\
0

Share this post


Link to post
Share on other sites
The rocket doesn't need to know about it's particles, that code goes in the Game/Level update function. A very simplified example:
[source lang="cpp"]void update()
{
rocket.move();

if(rand() % 5 < 1) //create a particle on 20% of the frames
particles.push_back(new Particle( rocket.getX(), rocket.getY() ) );
//or if you want smart pointers instead: particles.push_back(std::make_shared< Particle >(rocket.getX(), rocket.getY()));

for(auto particle : particles)
{
if( particle.isDead() )
//erase particle code here
else
particle.update();
}
}[/source] Edited by sednihp
0

Share this post


Link to post
Share on other sites
Sednihp thankts for the reply. But I don't think your getting what I'm saying.

if I fire the rocket 5 frames ago then going by the code above, the current position of the rocket would be half way across the map
but the emitter would still be at the starting point because the particle system does not control where the emitter is (The Emitter Is a point in 3d that the particles launch from, they have direction and stuf but thats not what where here for).

I cant just send a new request for a new rocket flame particle system because it would be at its starting of its particle motion like animation each time.

I'm thinking is I use a weak_ptr in the particle manager to hold a object pointer then this would be invalid when a object remove it self and then the
particle system can detect if the object dies and remove its self from the active list of particle systems ready to be used again.
Is that how smart pointers work.

No, looked into doing the above just then and now I'm going to link then old school style by a Index to the particleSystem the object is using
and a object pointer in the particle system to the current bound object to this particle system, It will be valid all times until the object die then
the object will use its index and remove its self from the particle manager, like wise if the particle system has finnished its animation it can use the
objects pointer to tell it to remove its self from the particle manager.
0

Share this post


Link to post
Share on other sites
I've linked the unit to the particle manager and also linked particle manager to the unit, I have not yet tested it, because when I ran it the first time
I could not see my particles 2 hours later I find they are small so now got it working but not tested yet.

here a picture of the particle system on the terrain and unit

[img]https://reg8dw.bay.livefilestore.com/y1pXH8K1b7EvUKwjJ1yxaWN1jbLYtm1LV2m07Zb63UiPNn6M09FSsnQaacXwPEuxfSWYNGxg5B0MiO5lkWqMCBCj7J8QS9kkWqY/LinkingParticleSystem.jpg?psid=1[/img].
0

Share this post


Link to post
Share on other sites
ankd,

What sednihp said is correct for your typical particle systems. "Particles" are typically just residue left from an emitter. Once a particle has been created, it doesn't matter where the emitter is. Think about a car with bad exhaust. When the smoke (ie, the particle) leaves the car, it just starts floating up. It doesn't care if the car has turned left, it's doing it's own thing once separate from the car (ie, the emitter).

In simple games, a particle could just be a small block of red/yellow/orange that is created by a rocket, and fades away a short time after to look like some kind of fire (when combined with many particles). These particles don't care where the emitter is once they have been created.

It sounds like you are trying to define something else, not the typical particle emitter.
0

Share this post


Link to post
Share on other sites
ok this is the last time i'm going to say this. This is not about the particles its about linking the emitter to my objects.

My particle systems are define to do a certain task, Eg. Muzzel flash it luanches 50 particles that come from the emitter at some direction.
This emitter can be moved around but that only changes any new particle that is launched, at its new world position.

Now ParticleManager managers a bunch of particle systems that do there own thing and each one has a world position emitter that I would like
to set at runtime, like when a unit walks. ParticleManager also adds request from objects when a object need to activate a particle system.
It's at this stage, I would like to link objects that are bound to the particle manager and what one it is using, and like wise with the objects.
So what I have done todate is in the particle manager when a unit adds a request I also store a pointer to the object and the add function
returns back to the unit data containing where and what elements its in.

Now when a unit dies or no longer needs its particle system it will message particlemanager to do so.
all good so for but none of my objects have death built into them yet and Im also in the process of making the rest of the particles,
I'll get back as soon as I can with the test results.
0

Share this post


Link to post
Share on other sites
Oops, my bad. I did misunderstand.

So, my initial thought is there may be a design flaw with using a "particle manager" to control the emitters. I would have the emitter itself (which is given to rocket) handle how it renders and processes the particles. As for when it needs to be removed, it could come from the rocket (or whatever object is using the particle system), and that object removes the particle system (emitter).

The specific emitter can be copied from your vector of the possible systems, but you're getting into trouble having to share it across multiple objects.

There are a number of posts throughout discussing the pitfalls of using "managers" You can search through and find them.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0