Jump to content
  • Advertisement

Viperfourfive

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

131 Neutral

About Viperfourfive

  • Rank
    Newbie
  1. So it looks I was looking for something like the following...  Since There is no direct conversion for "?" in C# from Java. System.Type type = typeof(className); & objectName.GetType(); I think, I'll let this thread die now.  Thanks @phil_t for helping me think about this from a different perspective.
  2. After re-reading through a bunch of articles, I came across this again; which lead me to the source code on github.  Going through this again answers my questions from the OP on "What is the bare minimum required"?  However, there is a few things I need clarification understanding. In the EntityManager, he defines (in Java) HashMap<Class, HashMap<Integer, ? extends Component>> componentStores; My very limited knowledge of Java means this should convert to C# like: Dictionary<??, Dictionary<uint, IBaseComponent>> componentStores; Now, I cannot say "class", intellisense doesn't allow it.   But is there anything wrong with using "Object"; it's the base class of all classes.  Or do I want to continue to use my empty interface "IBaseclass" that all of my components inherit from?  *edit* Also, my original thought was to use the following: Dictionary<uint, List<IBaseComponent>> componentStores; This way, when an entity expires, I can kill it and all values assigned to it, by just freeing the key using the uniqueID I've given to it.  I don't see the benefits to storing the nested dictionaries<>;  if someone knows why I would definitely want to hear why.
  3. Crystal clear.   Yeah, which I think I recall myself saying I liked when systems and components separate themselves.  I guess OOP habits die-hard, and since I'm trying to say with an ES model I definitely want to stay away from this.   So, the SystemManager is really just a class that calls all of the other systems, sort of a fail-safe.  So, that one does not render before updating the position of a sprite; or something similar. Which really only leaves me with questions regarding the Entity class itself.  At the very least I think all I need and id, a container for the components(for each id), an add function, and a remove function.  So I need: to instantiate Entity in my main use it to call _e.AddComponent(new component(position)); repeat for all component for each ID.   use _e.Remove();  when something is deleted from the game world.   Does this sound about right? It doesn't to me, because I'm not using to ID to assign any sequential ID's.  It seems like I want to use a dictionary<> to link the id "key" to the component list "value"?
  4. Feel like I'm spinning my wheels.
  5. Good, I think I'm in the right frame of mind here.  I'm using classes for each of my components currently, all of which inherit from a "BaseComponent".  Unfortunately, I'm unsure what to put in the BaseComponent, besides: uint id; and string name; which after reviewing your component class seems wrong.  You have abstract classes (with only methods, no variables..). After a bit of reading today I was planning to use Interfaces in my baseComponent class and give it an Update(). To my understanding, derived classes need to have the same methods as the interface; and they both (abstract and interfaces) seem to be doing the same thing here.  Is there a right or wrong way here or just style?  Honestly, I don't think my game will run into performance issues, due to it being so small.  I just want to get some practice in learning ECS > OOP. Thus, I think using reference types over value types shouldn't be a big deal.   In a sense, yes, but Artemis has an Entity Manager, Component type manager, system manager, etc (look in the manager folder, they have tons).  I also don't like the idea of having any system own a component type.  To me, all data should be stored in the components themselves; with no methods.  And the systems should have all the methods, with no data.   But that's what I don't understand, if the components are separate from the systems, why do we have the managers?  Shouldn't you just be invoking calls to the specific system that matches the component?   Actually, I think you answered it.  They don't have to instantiate in "Entity.cs" or where ever.  Because the method doing the calling (typically in the game loop) is already instantiated.  It then, is just passing the variables it needs along to the correct classes method.  Did I understand that right?   I feel like there is still a bunch questions I need to ask, but before I do I want to re-read your BomberMan article.  However, I do want to ask one more question.  You use {get;set;} alot in your Components, is this becuase you're just pulling the data from your "prefab" or templates?  Is there anything wrong with just leaving the values hard coded into each component?  And instead of using prefabs just creating a new component with the new values you want?  Is using the prefab really that much faster and what are the benefits? Thanks for getting me one step closer to understanding this, I really do appreciate your time.  
  6. I have a rather long list of material (source-code, blogs, articles, powerpoints, stack-exchange posts, etc) that I've read on the topic, and I feel like I  have a good understanding of why using a structure like this is beneficial.  However, in practice I'm having a hard time implementing it.  I know that: Entities - Should only be an id.  AND that it should contain a list of components that link to that id.  Basically, "bagging" components that would represent and object in the game world. Components - Should only be data.  Ie.  A position component in a 2D game would represent the Vector2 values for X & Y. Renderable component would be a bool value, allowing the objects position to be passed to the rendering system. Systems - Are just methods containing game logic.  Ideally, operating in loops, and processing similar data before moving to the next method. Ie. processing all physics data for all "active" entity id's, before moving to the render method.  Doing this help increase cache coherency.  My problem, is that I'm having trouble applying these concepts into the basics of basic; Hello World. Part of my problem, is that alot of the guides and code I've read are in C++ or Java (which I don't really know) and I'm using C# to take advantage of XNA/Monogame.  For instance, most of the C++ examples use pointers to reference the component class.   Component* component = Component[num_components];  From my limited knowledge of C#, pointers are basically useless.  Unless you want to mark it as "unsafe" and flag it that way to everyone that runs the app.  So, what should I be using instead of these?   Digging into the source code for the C# ports of Artemis & Ash seem bloated with extra features.  Because of this, I'm having a hard time understanding exactly what methods are actually required and where to draw the line.  I realize that this system is complex and requires a bit of "start up overhead", for lack of a better term.  But, to me, that shouldn't mean that I need Managers for each one, right?  Another thing I don't understand is that source code examples (from many languages), pass Component component (Class/name - respectively), like: public void AddComponent(Component component) { //do stuff } However, they never actually instantiate "Component" anywhere in Entity.cs.  How does it know to pass this value correctly??   I'll be honest, I have no intentions of building my own engine, and I think Artemis is eventually what I'll be using for my project.  However, I feel that in order to use such a system, one should at least understand the basic principles that make it work; to me, not doing so is a very serious mistake.  I feel that if I just keep reading the same articles on this I'm not going to get anywhere.  Can someone help point me in the right direction?      
  • 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!