Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

165 Neutral

About jaeg

  • Rank
  1. jaeg

    Inventory System

    Yep that's almost exactly how I have it right now.  Then for my Inventory class I have an "addItem(Item item)" function.  It iterates through the list to see if the item has been added before.  If it has then it increments counts by 1 otherwise it'll create a new slot and set count to 1.
  2. I've been messing around making some small elements of an RPG game engine.   Just today I've gotten a dialog system that pulls from XML all the NPC messages, user options, and some data that can trigger actions within the game (start quests, give gold, etc).  I even made a dialog editor so that it is easy to add new messages to a dialog as well as define as to where a user option will take the dialog in the xml.  I.E.  Say "I'm done talking" will lead to a conversation ending message while "Who are you" takes you to a message about who the person is.     After I did this I got bored and started work on an inventory system.  I've gotten it so that I have a base class Item, a class for managing inventory called Inventory, and a kind of data in-between class called InventorySlot that stores a single Item and an integer stating how many of that item is contained in this particular slot.   My concern is this, I work with MySQL all day at work and this InventorySlot class would make since as table but for a game (in C++) is this good design?  Or should I be doing this some other way? I thought about doing a 2D array where [][0] would be the item and [][1] would be the quantity. However this would make the inventory size a constant.  Using inventorySlots I can keep them all in a Vector and expand/shrink it as I need to.   Thoughts?
  3. [color="#1C2837"]When you say units, are you implying that you have like a master AI system and then child AI subsystems? Then those child AI systems can request from the parent AI subsystem pointers to the various AI child systems to communicate back and forth and work with other various AI components without using the event dispatcher? As for your comment about see/hear rules, I don't follow.[color="#1C2837"] [/quote] I'm thinking my AI system is more complicated than yours. Rather than just one part running scripts there are other systems for things like sensory input. These systems watch for things like sounds to play or check via rays if the entity can see another entity. These will notify the decision making system which looks at the data and decides what to do. Using this I can effectively turn off a monster's ability to hear and it would function as if it never had it. Some with vision. I could turn off it's ability to receive a list of objects it can see making it have to solely by hearing find a target. The ai has a set of targets kept in a list and when it gets it's vision feedback it'll compare those objects to the target objects and then take the right actions to try to kill the player. So in short all of these systems make up the AI system as a unit. If one system doesn't exist the unit needs rules to make sure it can still operate. Best example of what I'm doing: Left 4 dead AI [color="#1C2837"]It does make sense from the perspective of keeping things simple, but I decided to take a different stance when I started. With the editor in mind, I will be able to construct my terrain, shape it as I wish. Additionally, the editor will allow me to place an entity (broad-term) anywhere on the scene. The entity being placed can be selected in two ways 1) pre-fabricated or 2) dynamically. The user will be able to create a monster by simply selecting and dragging components to the entity container, setting values and moving the entity in the scene where they want it to be placed. They'll be able to script in behavior or add AI elements by specifying path points, etc; all because of the components that a selected entity has. The users can create a silly entity and if they like what they have, they can easily with a simple click copy an entity to a pre-fabricated template. Later when they move on to another area, they can grab that entity from the pre-frabricated list instead and simply tweak parameters as they need. It's a big project no doubt, but that's the goal and with that in mind, I am of the opinion that entity components are somewhat dynamic. It certainly adds a bigger element of complexity [color="#1C2837"]. [/quote] This is where considering certain parts as units would come in handy. If you give them the option of choosing what input the ai should receive so when the decision making part of the AI unit does it's thing it'll look to see if it has the ability to hear or see. [color="#1C2837"]One current debate I have with all this is where to draw the line, particularly where it surrounds the render engine's components, such as lights, meshes, planes, and movable text, etc. Most of these objects require access to the scene manager for their respective render engine equivalent to be created. One way I considered is that all these "specialized subsystems" are child component systems of the render system. So when the render engine starts, there are about 10 different subsystems that start up with it. These subsystems handle various render-component types. Another alternative is that I have 1 system that manages all these components in various lists. The downside here though is I end up with a laundry list of logic methods in this one system for various component types; albeit they all depend heavily on the OGRE render engine to work. I just can't seem to put my finger on a good design for these types of components.[color="#1C2837"] [/quote] I'm not sure about OGRE but in Irrlicht things like text is handled by the GUIEnvironment. So maybe have that as either a separate system. A light that can change it's state should be an entity and in Irrlicht I think is still considered a scene node so the renderComponent which stores said node can still hold a reference to it.
  4. I'll probably make two tools. An entity generator and the level editor.In my system the blueprints for entities are stored in .init files that are parsed by the entityFactory creating the components in the correct order. So before actually constructing a level in an editor I would go through and create the entities I.E. enemy types, pick-ups, weapons, and other dynamic stuff. After I have designed them for their purpose the generator goes through and using it's set of rules makes sure the components are listed in the correct order. Note that the generator does not need to use the components so it doesn't have to have them added to it in the correct order either. (I hope that made sense) The level editor on startup will look through the "scripts/Init" folder find the entities available to it and allow you to place them in the level. As of right now I don't need to come up with new entity types on the fly I just plan to use the ones I have planned out ahead of time. It keeps things simple for now. I've been going through and writing notes and drawing diagrams using the systems as the updater and the components as data-bags and I'm seeing why you do it. It's easier to communicate data between components via the systems. Same with system to system. To me it seems like multiple systems with dependencies on each other should be considered as units especially ones that function together to form AI. So those components need to be made together anyway so the dependency shouldn't really be too worried about. Now using AI as an example again since not all entities need to hear or see rules can be made to exclude those from the system that stores the action queue or makes decisions based on those two's input.
  5. [color=#1C2837][size=2]This is my 100000 ft view on where I plan to head, but not sure whether that is right [color=#1C2837][size=2]. I'm still working on basics [color=#1C2837][size=2]. [/quote] Same here. As I work on it I find that certain things don't work (problem I'm having right now) and that certain things do. Also that certain things work better with others. Coding isn't hard it's designing it first. The nice thing though is that I have it set up in a way that I could complete remove the entity system without having to rewrite other parts (stateManager, game) since they are independent of each other. I know that isn't impressive but it's a first for me to design things modularly like this. lol I need to sit down list what I need in the game how things need to work based on the players view and from there figure out how it needs to work behind the scenes. I also think I'm going to drop CopperCube/irrEdit and make my own editor so that I can decide what components are applied to what and have it generate the .init files for me. But first things first I need to figure out what components I need. Like for example: A playable entity needs a component for: Spatial, Render, Animation, Collision, Controllable, Equiping. A weapon would need: Spatial, Render, Animation, Behavior, and Equipable. AI NPC (Zombie): Spatial, Render, Animation, Collision, Sight, Hearing, AI Logic. And if I'm thinking right it should be created and updated in the order I listed the components. Now for the components Equiping and Equipable: My thinking is that since every weapon has it's own behavior and other attributes making it able to attach and receive input via a entity with an Equiping component which receives controlling events will let me be able to use it easier.
  6. So if I'm reading right your actual system is updating the information based on the component data rather than having your component have an update function and it does it's task? So for example a collision system just pulls the data from the current component it's looking at and updates the data based on that itself? I can see that working for some of the components but what about a more complex component like AI? In my system I have two AI like components. AI and Behavior. Behvavior runs a simple script while AI deals with more complicated inputs and outputs. EDIT: I found an article that I think is explaining what you are talking about correct? Entity Systems The point your making is about halfway down the page under "Almost"
  7. So you seem to have kind of a game view system going on then don't you? So if I'm understanding right your animation system isn't in a component then? For my purposes I'm thinking of making it a component that just listens to events from it's ID. I'm thinking of changing my event system to use more type specific events inheriting from a base event. Currently my events look like this: struct Event { EventType type; EventCategory category; void* data; }; type and category are large enum lists. When an event is called the dispatcher sends it to the handlers registered to receive specific categories. I'm thinking of changing it so I can get rid of *data and just make more detailed events. Since the handler will know what it is based on the category and type it'll know what to cast it as to get the data from it. Also I'm thinking I'm not using it as much as I should. Right now it's just used to give the stateManager feedback on the states it controls like if in the menu a button that should make it switch states is pressed. Or in my CGame class (the engine class that controls if the game is running, sets up application stuff, ect) it uses Irrlicht's eventReciever to get keyboard inputs and broadcasts that. I hadn't thought about have entities use it to send that it moved or not. Also what is a good way to manage the event objects produced? They aren't pointers I make them like this: Event event; event.type=E_CREDITSSTATE; event.category=E_GAME; CEventDispatcher::inst()->sendEvent(event); That sends to the stateManager (who is registered to listen to game events) an event from the menu state to switch to the credit state. Do I need to delete the event after it gets used or will it go out of scope and disappear itself? The CEventDispatcher calls all of the IEventHandlers->handleEvent(e) functions in the registration list for that particular category. It's up to the handlers to decide if they ignore the event or not.
  8. Right now I think I have insufficient communication abilities between my components/systems. I need to rethink my messaging system. Especially when it comes to data sending in events. Void pointers to specific data objects does not cut it. Do you do your animation in an animation component or the render component? Also since as you said animations are more complex for you especially your player entity do you have multiple rendering/animation component types?
  9. I ended up having to cheat a little when it came to my animation. I ended up tucking my start and end frames into my spatial object and having the render object read it. That way the AI/Behavior components can change them when needed. I'll keep this way until I get my message system capable of sending the data itself. Or is it ok to keep it like it is?
  10. Is it ok not to have my components inheriting from a component base class? All of my systems deal with their own component type so the never use the base class and it's causing me issues like overloading the init function. Not all of the components need a CSpatial but it seems I have to overload it in the base class first then give each component derived off of it the function just to please my compiler.
  11. You are right. Irrlicht is just a rendering engine. It does have a collision system but that's for demonstrative purposes and probably shouldn't be used for actual games. (I tried and it was a big mistake). I love Irrlicht and use it in my engine but I also have to code a lot more things for myself as well. (The part I love to do)
  12. [color=#1C2837][size=2]Communication for me has probably been one of the hardest aspects of using this pattern. I am still by no means comfortable with my current approach but its a crude, elementary, but working solution that I look at being something I can tune and refine at a later point. [/quote] This tends to be my problem too. I'm not yet comfortable with my own design skills which is why I created this topic in the first place. I am feeling more comfortable with my current system now than I was before with the help of the people here. Now if my design is actually practical is totally another story. I'll find out soon after I get my entityFactory finished and parsing the levels I've already made.
  13. Do you mean pushing a pointer somehow to the lua_State in the init() function? Edit - Would it be better to do it the opposite way like described here? That way I just call a lua function from c++ and feed it the data instead?
  14. To do my AI I wanted to use Lua with registered functions to get information about the AI controlled entity and the world while also letting me modify it's position/rotation but I've hit a snag. As far as I know you can only register static functions. This leaves a big problem: Note this code has been gutted because I don't have the source with me and I'm writing it from memory and don't want to type the whole thing out. class CAIComponent: public CComponent { public: void update(); void init(); private: luaState* L; CSpatial* spatial; //pointer to object containing the particular entity's rotation and position; int id; //Entity id this component belongs to //Functions for ai script static int ai_position(luaState* L); basically in my init() function I open a luaState and register the function ai_position. ai_Position needs to access the objects spatial reference but it can't do that because it's static. Is there a way around this? Am I going at this design wrong?
  15. Should I make separate classes for the subsystems or could I just have a single subsystem class that has functions that let you decide what events they should receiver for the components they update?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!