• 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
Alex Melbourne

Component programming. I think?

32 posts in this topic

I would like to understand this too. A complete novice could come in and explain how to solve a problem with messages, but we have not yet had a coherent example using flags. So far it sounds like you somehow cache the content of the messages in one of the components, and have every system come along and look at the list later. Not seeing how that's better.
0

Share this post


Link to post
Share on other sites

Sorry for pushing this, but to make my point, we need to go into depth. Suppose the solution with a VisualEffectComponent is used. I suppose this would be a temporary component? That is, it is added for this purpose, and removed when "used"?

It could be a temporary component, yes. The alternative would be to make it permanent and have it store an empty list most of the time, but then the interested systems would waste time iterating over it to only find an empty list. If it's temporary, systems can create and destroy it as they deem it necessary. However either approach technically works.

How would you implement the sound effect? Would you create a "SoundEffectComponent" for that? How would you create the log message in the chat window, would you create a "LogMessage" component for that?

The effect component would contain an abstract description of the sound effect, and the sound effect system would just play it using whatever sound library the engine provides. There is no sound effect component to be created. Likewise there is no need for a log message component, whenever a system needs to log a message it just does so using the logging API, or sending an event that the UI can listen for to display a visual message.

Now back to the other proposal, using a "DamageComponent". I suppose this solution would also be a temporary component, which is removed when used? If so, who would have  the responsibility to remove the component again? How long will the component stay attached on the entity (monster)?

This would be a permanent component, the existence of which also acts as a 'tag' (or 'aspect' if you will) to indicate that its parent entity can take damage, and thus any systems that deal damage for whatever reason should be on the look out for these entities. Removing the component would mean the entity can no longer take damage, which could be a very helpful feature during development.

Please enlighten me, what kind of data will you store in the achievement component to solve the specific achievement problem i listed above? The example I had was an achievement where the player had to hit a number of monsters with arrows in a limited time period. How would you solve this with an achievement component?

Whenever damage is done to an entity (which would mean it has a DamageComponent), the system applying the damage would also log an event, some packet of data, to the AchievementComponent of the attacker, if they have one. In this case only the player entity would have this component. If you log information pertaining to which entity was damaged, at what time, and with what weapon, the achievement system then has all the information it needs to determine whether the player hit a certain number a monsters in some time period. At that point it's just a data-mining problem: query all the damage events that have occurred in the past 10 seconds, with an arrow weapon, and count the number of unique monsters. If it's greater than or equal to 5, award the respective achievement.
1

Share this post


Link to post
Share on other sites

I would like to understand this too. A complete novice could come in and explain how to solve a problem with messages, but we have not yet had a coherent example using flags. So far it sounds like you somehow cache the content of the messages in one of the components, and have every system come along and look at the list later. Not seeing how that's better.

I think I've provided a few coherent examples, but that's just my opinion smile.png You might be missing the forest for the trees and focusing too much on the message-passing aspect of the design (or lack thereof), which is really just a side effect of removing all logic from components so that they no longer can communicate directly. Instead of components responding to messages from other components, systems respond to all changes in component data and make further updates to components as necessary. It's an inversion of responsibility, where instead of individual components trying to wrangle what happens to other entities and components in addition to themselves, entire systems become responsible for these tasks. As long as you adhere to that guiding principle, everything else is pretty much an implementation detail - which components are permanent vs transient, how systems can communicate with each other, how systems know when they need to run, and how often, etc.
1

Share this post


Link to post
Share on other sites

Whenever damage is done to an entity (which would mean it has a DamageComponent), the system applying the damage would also log an event, some packet of data, to the AchievementComponent of the attacker, if they have one. In this case only the player entity would have this component. If you log information pertaining to which entity was damaged, at what time, and with what weapon, the achievement system then has all the information it needs to determine whether the player hit a certain number a monsters in some time period. At that point it's just a data-mining problem: query all the damage events that have occurred in the past 10 seconds, with an arrow weapon, and count the number of unique monsters. If it's greater than or equal to 5, award the respective achievement.


If I read that right, every system has to be aware of the achievement component, and has to log everything that ever happens because achievements can be triggered by any weird combination of factors over any time period. And the achievement system has to mine a huge amount of data on a constant basis. Whereas using messages and an observer nothing else needs to know that achievements even exist, and the overhead is minimal.
0

Share this post


Link to post
Share on other sites

Whenever damage is done to an entity (which would mean it has a DamageComponent), the system applying the damage would also log an event, some packet of data, to the AchievementComponent of the attacker, if they have one. In this case only the player entity would have this component. If you log information pertaining to which entity was damaged, at what time, and with what weapon, the achievement system then has all the information it needs to determine whether the player hit a certain number a monsters in some time period. At that point it's just a data-mining problem: query all the damage events that have occurred in the past 10 seconds, with an arrow weapon, and count the number of unique monsters. If it's greater than or equal to 5, award the respective achievement.


If I read that right, every system has to be aware of the achievement component, and has to log everything that ever happens because achievements can be triggered by any weird combination of factors over any time period. And the achievement system has to mine a huge amount of data on a constant basis. Whereas using messages and an observer nothing else needs to know that achievements even exist, and the overhead is minimal.

 

Achievements are always going to be a data mining problem regardless of where that data is stored or how it gets there. You simply replaced logging events to a component with sending a message. In either case, the code needs to know that some event X is "significant" enough to be stored to a component, or in your case warrants a message to be sent. The fact that it's called the "achievement" component is irrelevant; you could instead call it the "stats" components to make its purpose less specific and more reusable (and this is probably what I would call it in a real design), but it would still need to store data required to evaluate achievements. And if a history is required to evaluate a particular achievement, then that cached data isn't suddenly going to go away when the data transfer mechanism changes.

 

Achievement systems always tend to require very specific data to be collected across multiple gameplay systems, and often times that data isn't relevant to anything but achievements. So we can tell ourselves that we're collecting monster damage data for some unknown yet hopefully non-specific, reusable purpose, but in many cases the developer just had to add that data logging to be able to award some achievement somewhere down the road, and otherwise that data is useless smile.png

0

Share this post


Link to post
Share on other sites

Also, just to be clear, I'm not advocating the complete removal of events or messages from the design. All I'm saying is that the components themselves should neither send nor receive these messages. The systems, however, are free to communicate among themselves. As a matter of a fact, signaling would probably be the most efficient way to handle the achievement system, since it only needs to run occasionally. Whenever another system modifies component state that could affect achievement status, it sends a signal to the achievement system to wake it up. The achievement system runs once, awarding any achievements it detects, then goes back to sleep until it receives another "reevaluate" signal.

1

Share this post


Link to post
Share on other sites

All I'm saying is that the components themselves should neither send nor receive these messages. The systems, however, are free to communicate among themselves.

 

Ah, then I agree completely. It may be we argued around a misunderstanding.

0

Share this post


Link to post
Share on other sites

As a matter of a fact, signaling would probably be the most efficient way to handle the achievement system, since it only needs to run occasionally.


Well, that was my point. Agreed then.

Where the logic lives isn't a great concern to me; as long as the most suitable algorithms can be allowed to work.
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