Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

126 Neutral

About riverman_paul

  • Rank
  1. Hey everyone, this is Paul from RiverMan Media. I always imagined that there were probably similar systems out there when I came up with the idea. What might be unusual about our version is how it works in conjunction with our Behaviors system, which is a like a hybrid between pure composition and a pure type heirarchy for game objects. I gathered from our discussion on Behaviors on this forum that such a hybrid system is less well-known in the industry, but I really like it :) I think that the Behavior System and the Scripted Event System have a strong synergy when used together, perhaps more so than a pure component system or a pure type heirarchy would have with scripted events. Scripted Events don't necessarily benefit from a pure type heirarchy because game object behavior is not separated from the object itself (and thus you can't put that behavior into the script). However, a traditional type heirarchy does make it easy to deal with the code executed when the listening object hears the script's callback. A pure component system does take advantage of the fact that the components themselves could be script elements, but the listener code that would go into the game object would also have to be a component. In this case, the component system requires that you write a bunch of components to handle all of the different code that is executed when the script's many different listeners hear the script's callback. The components also have to deal with the communication between script and listener. The Behaviors System, as the hybrid between the two, combines the benefits of both. Much of your game objects' capabilities/actions are already encapsulated into Behaviors, which can be part of the script. And dealing with the callback is easy, because each listener can specify what it wants to do when the script is done in its own code. I'm not sure if that made any sense, but it's my guess :)
  2. riverman_paul

    The Behavior System Revealed!

    Thanks homer_3! Both my brother and I love Tetris Attack, and we're giving it our best shot to capture the speed and depth of TA while making MadStone a unique experience that could only happen on the Wii. A question to the folks who have used a "pure component" system. About how many components does it take to make a complicated entity (say, the player character, or an enemy)? And how many of these components within the entity are active (i.e., executing code) at any given time? Since I've never tried to implement a full component system myself, I'm curious how large scope it is in actual games.
  3. riverman_paul

    The Behavior System Revealed!

    Yes, behaviors are similar to what some people call an intermediate or "hybrid" system of components, where it isn't pure composition or a pure type heirarchy. I agree that it's cool how in a pure component system you can create new objects "on the fly" or by editing a data file, and this isn't something you could implement as easily with behaviors. Thanks for explaining this! As you said, in a pure component driven system, all you need is the components. True, but also consider the flip-side: all you HAVE is the components. If any functionality is tough to do with components alone, then you're stuck. With behaviors, you have the flexibility to use them as much or as little as you like. I definitely think that pure composition will fit some game designs better, and other games will benefit more from behaviors. For example, if you're making a game with an extensive map editor usable by the player (like a strategy game), pure composition is probably the way to go. It will let the players create entirely new game objects without changing code or recompilation. On the contrary, if you aren't going to fully utilize those advantages of a pure component system, behaviors may be a better choice. Consider a game like a space shooter or puzzle game. You (the programmer) are probably going to be creating all the game objects, so you want the flexbility to do it however you want. If you want to use a normal type-tree with inheritence, go ahead and use it. If you want to use behaviors, you can use them too. I've personally found that game objects are diverse and lend themselves to many different designs, so I like the freedom to use both type-trees and behaviors. -Paul [Edited by - riverman_paul on May 6, 2008 2:03:54 PM]
  4. riverman_paul

    The Behavior System Revealed!

    Hey Sneftel, thanks for the link! I checked out that thread, and there was a lot of good info there. So basically the two original problems discussed in the thread were: 1. Sometimes components in the same entity need to be able to access each other. 2. Sometimes components from different entities need access to each other. It seems like with the pure component system discussed in the thread, these two cases are difficult for a couple reasons. First, being a pure component system, the entity doesn't store any data (other than a list of components). This makes it tough for components to communicate with each other directly because the entity can't help them talk to each other (e.g., by passing them references to each other). Components also don't have any easy way to talk indirectly (e.g., by modifying data in the entity). Second, storing all the components of an entity in a list means that you have to search the list whenever you want to find a specific component (and probably cast it once it's found, since the list stores the generic Component type). I haven't encountered any problems like this with the behavior system. I think it's because parents can store as much data as they want, including persistent, typed references to their behaviors. It's inherently easy for parents to pass behaviors to other behaviors, which gives the behaviors direct communication and as much knowledge of each other as they want. It's also no problem to give behaviors more knowledge of their parents, allowing behaviors to communicate indirectly. Whether the behaviors come from the same entity or different entities, there are plently of options for facilitating communcation between them. Does this make sense, do you think Behaviors adequately address both issues? NotTheCommonDose: Behaviors don't work exactly like a standard component system. All GameObjects have an update() method. Subclasses that extend GameObject (like "Monkey"), override this update method, and call whatever updating code they want, including calling update() on any behaviors that they are using. The behaviors are instantiated whenever you want. A solid example of how Behaviors work in the parent class is discussed on page three of my Behaviors article. If anything is still confusing let me know.
  5. riverman_paul

    The Behavior System Revealed!

    I have a few questions for the people who have brought up similar systems (e.g., composition-based, aspect oriented programming, and the controllers). There are a couple principles that are pretty important to how the behavior system (specifically) works, and I was wondering if the other systems follow these same principles: 1. Behaviors and their parents are stronly typed. A parent object must implement a specific interface for a behavior to connect to it. No casting is ever used, and there are never any conflict issues between the behavior and its parent's type. 2. The parent object stores all of the basic data for the entity as a whole, e.g., its image, position, alpha, scale, etc. The behaviors store only the data that they need internally to modify the parent's data. This means that most of the data stored by the behavior is irrelevant to the parent, and because of this behaviors don't conflict with each other. The only time behaviors might step on each other's feet would be if two of them are operating on the same data of the parent at the same time unintentionally, which has never actually happened in my experience. 3. Behaviors supplement a normal, heirarchical inheritance system, they don't replace it. For example, Howler Monkey still extends Monkey, Monkey still extends GameObject. This preseves all of the benefits of inheritance and polymorphism while adding on as much composition data as you like. It's ~sort of~ like getting all the benefits of single inheritance, along with most of the benefits of conflictless multiple inheritance (due to the strong typing). Do the others work like this? Thanks! Paul
  6. riverman_paul

    The Behavior System Revealed!

    Hey all- NotTheCommonDose: BlodBath is right, there are several ways to update all of your GameObjects without calling update() on each one manually. If you use a list, as BlodBath suggested, that usually works great. In some situations (like grid based puzzle games) you may want to store them all in a 2d array and update each element of the array. It's much easier to do it this way if you want to ensure that all your objects update() and redraw() in a specific order, which is critical to the logic and drawing of a game like MadStone (video: here). If they didn't update in order (top to bottom), falling objects would get out of sync with each other and the physics would be messed up. If they didn't draw in order, you'd see random chunks of blocks drawing in front of other ones.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!