Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

100 Neutral

About JasonWelch

  • Rank

Personal Information

  1. To keep this post as short as possible, I am using a composite design for all game objects, which all are either an instance of GameObject or of a direct descendant. I'm working on integrating box2d into my game currently, but projectiles have been stumping me a bit. Right now, projectiles are an instance of BaseProjectile which extends GameObject, and then an instance of ProjectilePhysicsComponent gets attached to them. When the game loads, I pre-cache x amount for each weapon depending on the rate of fire. This way, projectiles get treated like particles and are simply recycled once 'dead'. However, just the idea that a projectile is a game object, just feels off to me... It may make sense to call a rocket a game object, but simple "dumb" bullets that do little else but spawn at X location and move at a set velocity...but then, they do need to tell the colliding object about the collision (such as telling them how much damage should potentially be applied). I guess in the end, both the game object and base projectile classes, are relatively small objects.. but I'd still like to hear you're guys input on this. How are projectiles defined in your games? Edit: as a side note, let's say my current design is fine.. I need a way to sync the states between the game object and physics body, but I don't want the physics component to have a bunch of methods such as "onFire", "onExpire" etc. Maybe the projectile class itself should know about the physics body? Hmm. Maybe it should be an exception to the composition pattern and not contain any components at all, other than maybe for drawing. Hmm.. definitely need some feedback here please!!
  2. JasonWelch

    Handling a damage event

    [font="Verdana"]Thanks for all the replies..very helpful! Nanoha, an idea for you is, send the event twice..once to the entity only and once to the world / game listener..can't hurt. Anyway, the way my system works is, every type of component gets registered to an associated subsystem. Subsystems can be inherited, same as components. The entity itself gets managed by the GameWorld where as it's RenderComponent registers itself to the RenderSystem at startup/unregisters at shutdown. The game world and subsystems know nothing about each other. However, I was thinking of making a global "EventBoard" which subsystems can be registered to..for example, "PlayerDeath" maybe sent to the EventBoard so that the AISystem can react accordingly.[/font] [font="Verdana"]Here's a small example of the system with a 2D "player" object: [/font] [font="Verdana"][/font] [font="Verdana"] protected GameObject createPlayer(float x, float y, RenderSystem renderer, PlayerInputSystem playerInput){ GameObject player = new GameObject(); Material mat = new Material(); mat.setTextureFile("zombie.png"); player.setMaterial(mat); player.setPosition(new Vector2(x,y)); player.addComponent(new SpriteRenderComponent(renderer,player)); player.addComponent(new PlayerControllerComponent(playerInput,player)); player.addComponent(new MovementComponent(player)); return player; }[/font] [font="Verdana"] [/font] [font="Verdana"]Anyway, after reading all of your replies and doing a bit more thinking... The explosion will be a new entity that gets spawned during the explosion. Attached will be an ExplosionCollisionComponent which the collision system will handle just as any sphere collision. During the collision check, the component will send the damage event to all successful colliders. This even can then be passed down from the component to it's associated entity, which may in turn, send it to all of it's other components. [/font] [font="Verdana"]But..[/font] [font="Verdana"]I don't like that idea much. I don't like how it's being passed from one component, to the entity, then back out to all other components...So I'm thinking that the event will be given to the onCollision method of the targets, which will pass it directly to the parent entity and back out...so CollisionComponent::onCollision(other, Event event); Note that I do use type casting for events, but only for events...so the above would be:[/font] [font="Verdana"]if(event instanceof DamageEvent) {[/font] [font="Verdana"] DamageEvent damage = (DamageEvent)event;[/font] [font="Verdana"] // do whatever here..[/font] [font="Verdana"] this.getParent().eventCallback(damage);[/font] [font="Verdana"]}[/font] [font="Verdana"]In short: The rocket explodes creating an explosion entity. The explosion entity's collision component then get's access by the collision manager which performs the check based on some spatial data. All objects within the explosions node radius, get checked against for collisions. If a collision occurs, a new damage event is generated by the rocket's collision component, and passed to the collision event handler for the colliders. [/font] [font="Verdana"] Thoughts?[/font] [font="Verdana"](ps..I'm literally falling asleep at my kb right now..hahaha)[/font]
  3. JasonWelch

    Handling a damage event

    Thanks for the reply skuzzbag! (it feels like I'm insulting you haha). Now, would you say I should pass the damage event directly to the target object?? Edit: Example: target->eventCallback(damage_event); Since damage being dealt is an event rather than a collision event.
  4. [font="Verdana"]I'm trying to figure out the best way to handle damage events. I figured when dealing with localized damage such as the impact of a bullet, the bullet can generate a damage event and pass it to the entity's collision component, which may then pass it to the entity itself which in turn would pass it to the other components that care about it such as life, render, etc. This seems pretty logical to me but I'm open to suggestions, however my main question is with non localized damage events.[/font] [font="Verdana"] [/font] [font="Verdana"]For example, a rocket explodes and should notify all nearby objects. This could be an ExplosionDamageEvent. Anyway, where would I broadcast the event? To the collision system? Eh.. to the life system? Maybe. What about AI? AI should be able to hear an explosion. I'm thinking maybe a global event system that all subsystems are registered with, will work. If the subsystems cares about the event type, they'll pass the event down to the registered components... but then, when the life system receives the event, how will it know if the explosion event affects it? If 300 entity's get the event and only 20 are within range of the explosion, there's still 300 distance checks being performed. The solution is obvious though: there needs to be a spatial division system such as a quadtree. However, what will query the quadtree and when will the affect entity list be created? The only thing I can think of is, the rocket could send the collision system the explosion damage event which would contain a collision volume. Based on the collision volume, the collision system would notify all registered collision components within range of the damage event. The collision components could then react to the explosion and could also send the event to their parent entities which in turn, the entities can pass the event to their other components such as life. This[/font][font=Verdana] sounds good to me, but I'm inexperienced still. What are your suggestions??[/font]
  5. JasonWelch

    composite entities and java

    [font="Verdana"]Haha. I think I endured a decent beating here! Well, after a bit more thinking, I've figured out what I want to do. I'll use a very light inheritance (baseobject->gameobject for example). The base object will deal with managing components and such where as game objects will have all of the needed data for all dynamic objects. The components will register themselves with the various subsystems at startup and unregister themselves during shutdown. There will be no explicit named object types and in fact, the factory that creates objects, may just utilizes a scripting language such as javascript via the Rhino engine. I was aware of the fact that you were still technically subclassing even with unnamed classes, I just didn't word myself correctly here. [/font] [font="Verdana"]As far as animation however, where my mental block was is WHERE you would specify animation configuration data and where you would set the current animation state. I saw one solution where the state of animation was set accordingly to the entities current action (idle, run, walk, death, attack, etc). I think was thinking possible sending an event to the animation component instead that would tell it what state to be in.. I'll figure that much out later though.[/font] [font="Verdana"]Thanks for all of the feedback..I kinda feel like an idiot now XD[/font]
  6. JasonWelch

    composite entities and java

    Thanks for both of your posts. I agree exactly with both comments. I AM however, trying to focus on composition rather than inheritance, which was clearly defined in the title of my post... Anyway, my motivation for the idea, was more academic. I've been thinking about Ruby's "mix-ins" lately and how ruby's uses a more composite approach for things. I simply didn't like A: the idea of subclassing components numerous times and B: not having explicit control over what's going on within the entity. I will studying data driven design a bit more now however and as far as the rest of the comments, sometimes one just needs a little clarification in order to see things in the proper manner. I think my brain is just about wrapped around composition now, thanks!
  7. [font="Verdana"]I caught onto the concept of composite based entity systems several months back and ever since then, I've been struggling to find a solution that doesn't make me cringe. I of course can see the inherit issues with deep hierarchies (pun intended), however, I don't like the idea of having to subclass a component for each type of entity either. Another issue is that a purely composite system doesn't seem to always work in every scenario. Let's say I create an Orc entity that needs to have multiple animation states which get set depending on the current action. If my Orc is simply a "bucket o' components" I would need to create an OrcAnimationComponent which will control all of the animation state logic. It just seems to me that this is sort of defeating the purpose of a component system since OrcAnimationComponent more than likely, will never be used again for any other entity type. I recently created a system in Javascript which used a composite design, where using the example above, "Orc" simply created an instance of entity and pushed the various methods and data to it in order to "compose" the basic entity to be an orc. I've been thinking about how to apply this same technique to Java over and over again, and finally this morning, it hit me... In java, you have the ability to override methods during instance creation, without the need to create an explicit subclass. So what I am thinking I can do is use a mixture of interfaces, components and "behaviors" without ever needing to explicitly extend the entity! So my design is: //may possibly extend some factory class class Orc { public Entity create(...){ Entity ent = new Entity(...){ @Override public void onInit() { //maybe add components here.. ... } @Override public void onUpdate() { //add animation state logic here... } } return ent; } } Now, the above code sample, I admit, I do not know if member variables can be added to a instance of a class this way..but if so, an AnimationBehavior class which is akin to a component but is not meant to be added to the entity and forgot about, could be added for each state of animation. Within the onUpdate method, however you want to do it, you could set the current animation state there. Now I know the first thing people will say about this design is "but then you avoid compile time checks". I agree, that is a problem, but I feel it can be kept to a minimum with the use of components. I have not implemented this yet, but before I start, what are your thoughts on it? What pros/cons/flaws do you see with it? I'm more than open to your criticism! [/font]
  8. JasonWelch

    activating vs spawning

    Thanks for the reply. My friend was just telling me to stop always trying to pre-optimize. I'll do that...create them on the fly but preload their texture resources and such. Object pooling however may be useful for projectiles (create a large pool of them that all towers can share). As far as collision detection goes, I create a very simple quadrant system...a test a ran with 500 moving sprites, each performing collision checks on all other sprites, I went from about 15fps up to 90 with simple spatial separation.
  9. [font="Verdana"]I'm working on a small tower defense game currently. I just created the first revision of the level loader yesterday, but now I'm starting to think a bit how to handle the various waves of creepers. I can spawn entities on the fly into the world class, which doesn't impact the performance at all as I'm using pre-allocated arraylists (though I may step up and implement object pooling instead) but to me, storing up to let's say, 50 entities, just seems like it's going to carry a pretty high overhead on memory, even with textures/resources being shared. However, let's say I do just preload them all...[/font] [font="Verdana"] [/font] [font="Verdana"]Should the waves act as triggers in which the various entities listen for? That way, a wave instance can simply broadcast the activate message and then get destroyed...it doesn't need to care about the actual entities it's broadcasting to.[/font] [font="Verdana"] [/font] [font="Verdana"]and if not preloaded..[/font] [font="Verdana"] [/font] [font="Verdana"]The waves would need to contain a list of entities to spawn, on wave activation, spawn them all...and whatever resources need to get loaded, get loaded on the following update loop. This just seems to me like it'll bog the game down for a short time, but I wonder if really even matters.[/font] [font="Verdana"] [/font] [font="Verdana"]Opinions?[/font] [font="Verdana"] [/font]
  10. JasonWelch

    scripting, triggers and events

    That's awesome! Thank you! So I just read a small introduction here. It seems to me that behaviors trees are perfect for local decision making. However, I still believe that a trigger/event system would still be needed for actor/actor communication..Indiana Jones removes the golden statue which triggers the release of the ball. I guess however, the "ball" isn't an actor, however as it doesn't behave any certain way (physics could control the ball entirely). However, suppose a soldier actor spots a target and should tell the rest of his squad...he'd generate a "suspicious" event which may tell the other soldiers to follow the activator and be on guard...so basically, use the event to control which behavior node is used?? Hmm.
  11. JasonWelch

    scripting, triggers and events

    [font="Verdana"]Just realized I should probably also create several types of trigger events within Java such as touch, time, sight, location, noise, etc...these can then be exposed to the script.[/font]
  12. [font="Verdana"]Hello! [/font] [font="Verdana"] [/font] [font="Verdana"]I'm pretty new to AI programming, but I am familiar with event driven development. My game currently has a system for Behavior action events which can be anything that defined a behavior of an object. For example, AnimationBehavior, MovementBehavior, IdleBehavior, AttackBehavior...etc. I am also currently using javascript in some small places, but I decided from the beginning that I was going to eventually implement a much game logic as possible via script...to make it easier for others to work on without them needing a full IDE environment and compiler. I will admit that I do still get a bit confused with event driven development at times, so I'm sure that my trouble right now is probably because of that..but really what I am trying to figure out is WHERE things should be..[/font] [font="Verdana"] [/font] [font="Verdana"]For example, let's say I want a zombie to roam around until he spots the player (or a living human). Now, I figured that this is a local event to the zombie itself which can be handled via a behavior class such as "LookForHumans" so once the behavior spots a human, it sets the zombies target and notifies it that a human is in site, which then, the zombie (which is the controller?) will then react to the event by say, starting it's MovementBehavior with the targets position as a parameter for location (of course this would get updated every ai think tick). Once the movement is satisfied (ie. the distance between the zombie and the destination is within range) the movement behavior then sends event to the zombie... Now...here's one place I'm confused.. [/font] [font="Verdana"] [/font] [font="Verdana"][/font] [font=Verdana]if(event == movement) attack_behavior.enable()[/font] [font=Verdana][/font] [font=Verdana] [/font] [font=Verdana]but what if there is no target? Attack makes no sense. My though is this, though this is probably obvious... Simply create an instance of MovementBehavior called "move_to_target" which when it's received in the zombies event handler, it knows it's finally caught the target. The attack behavior can then simply notify the zombie again if the target is null. [/font][font=Verdana]Am I right in my think here as far as the basic AI goes? This in theory, will all be handled via script.[/font] [font=Verdana] [/font] [font=Verdana]Now, triggers and events... A TriggerEvent may be fired by another game object, such as a tile on the ground, when touched, would send a TriggerEvent like so:[/font] [font=Verdana][/font] [font="Verdana"]broadcast(new TriggerEvent("activate_poison_darts", this) // where as this refers to the (activator?)[/font] [font=Verdana] [/font] [font=Verdana] [/font] [font="Verdana"]Several questions here...[/font] [font=Verdana] [/font] [font=Verdana]My thinking is that, this would register the event with the AIManager which would then pass it along to ALL other actors. When the poison darts (or the object that shoots them) sees the event "activate_poison_darts" it then runs the method that fires the poison darts. This of course would definitely be a scripted event. However, where would this event be defined?? Should their be just a single script file for each level in which all logic for that level is defined? Also, in a case like the above, HOW will the script know when the object was touched?? It would need to listen for an event to be received it's self.. So using my behavior system...maybe have a ScriptedBehavior class and then exposed them to the script at run time? Hmmm.....[/font] [font=Verdana] [/font] [font="Verdana"]Also, what about game events such as "player_entered_end_zone"? Should that possible be done like: broadcast_game_event(...) in which a WorldListener listens for?[/font] [font="Verdana"] [/font] [font="Verdana"]I know this is probably quite a lot to tackle. I've been researching all of this for the past few days, but these are the things I was just really confused on how I might go about implementing...so thanks a ton if you help!![/font] [font=Verdana] [/font] [font=Verdana] [/font]
  13. JasonWelch

    Hierarchy WITHOUT Scene Graph

    [font="Verdana"]Hey Schupf,[/font] [font="Verdana"] [/font] [font="Verdana"]I'm currently working on the same basic thing. In my post, I believe I threw people off a bit by saying "Scene graph" because what I am developing IS NOT a scene graph, but rather simply an entity manager..a class to hold lists of entities and update them. As for your question regarding "a box on a table" well as you previously said "a ball on a table is not a child of the table, it is just a ball". The problem is, if you move the table, the ball should also move...well if the table and ball are both a represented in the physics system, this interaction should be nearly automatic. When building the level, you simply place the box on the table and let the physics system worry about the rest. However, let's say you want an entity to be composed of multiple entities (a composite entity). The way I am thinking more now days is that, you would build the entity class and simply add all entities that compose it as members. These entities should have an interface or class method for setting the transformation matrix in which you would simply update accordingly to the main entity's transformation matrix. [/font][font=Verdana]So in other words, think of entities as also being potential components of other entities. [/font][font=Verdana]I hope that helps you a little. I'm still new to the component concept as well, but writing that actually helped me understand a little better [/font]
  14. JasonWelch

    scene class design

    Here is a good example of what my current mindset is for the scene... http://code.google.com/p/libgdx/source/browse/trunk/demos/superjumper/superjumper/src/com/badlogicgames/superjumper/World.java In that code, granted it's specific for the particular game, they have several lists for each type of entity and then multiple methods for collision checks, rendering, creation, etc. What I am thinking is that, I could essentially use the basic idea, only, the entity lists would be more generic such as world entities, dynamic entities and logical entities. The render manager / collision manager / etc would then have methods for dealing with each type. For example, the collision manager would provide a method for querying dynamic entities within a certain radius of a point, same with world entities. A collision component then would be able to get these lists and then send collision events to each entity in that list. What I am thinking now though is that, entities should subscribe to these events..or rather, if they contain the collision component I guess that would be automatic. The entities then would have a collision callback method which the component would send the event too. A collision response component could then capture this event and then alter the entity as needed... This however all boils down to, should I have multiple lists for different entities or have a single entity list?
  15. JasonWelch

    scene class design

    [font="Verdana"]Thanks for your feedback. However, I am quite familiar with scenegraphs, composite vs hierarchical entity designs, etc. My system actually utilizes a composite based "behavior" design for entities (i.e. I have an IDrawable interface which various entities can implement such as DrawableEntity which is the base for multiple types of entities). Currently, I have a render manager in which I am passing a list of drawable entities to. However, the drawable entities list, I am currently building if the primary entity list changes, then just using a typecast in this instance, to build the drawable entity list. [/font] [font="Verdana"] [/font] [font="Verdana"]My primary concern with this is memory consumption (as I am building a game for android phones which are somewhat limited). The other concern was that doing this this way, may make it somewhat hard to manage. I also don't like the idea of having two lists storing the same entity references. I was thinking of instead, having a render callback method in the render manager in which a render component can pass a reference to instead. However, I want to batch multiple draw calls together, so either the render manager will need a list of drawables or as I am doing now, the scene contains that list. [/font] [font="Verdana"] [/font] [font="Verdana"]I guess to simplify my question, is it bad design to have multiple lists of entities in the scene...or rather, let's say, in the world as it's rather more of a centralized area to store and process entities. Hmm..maybe I should have the render component get the render manager reference directly and add have the render manager listen for it... I guess I just need to experiment until I figure it out. The main issue is that I am not too familiar with component based design.[/font] [font="Verdana"] [/font] [font="Verdana"]I know this reply is somewhat chaotic :/ [/font]
  • 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!