• 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.

chondee

Members
  • Content count

    49
  • Joined

  • Last visited

Community Reputation

135 Neutral

About chondee

  • Rank
    Member
  1. I'd guess Line 20: g.fillRect(spaceShip.xpos+[b]xOffset[/b], spaceShip.ypos+[b]yOffset[/b], 20, 10); where the offsets are the x and y distances from the top left corner of the spaceship to the point where you actually want it to spawn (middle of spaceShip)
  2. Thanks for your help, I'll try your example, my uncertainty in this topic is because I didn't work with custom << operator before.
  3. I guess it comes down to this: Do I have to sacrifice one of the following: [color=#ff0000][b]1. [/b][/color][color=#000000]String based color tags and macros[/color] [b][color=#ff0000]2. [/color][/b]<<Operator for string conversion of variables for this to be possible in a one line statement? Edit: If yes, than for THAT I could actually use a macro that aggregates the stringstream statement and the myFormattingCout(stringstream.str()) If it is however possible without a macro I would rather take that, so please let me know if you think it is.
  4. Thanks for your replies doeme and mrjones! The reason I would like it string based, that in that way I could also parse text from files that will be formatted and colored the way I want. The reason I don't want to use hardcoded macros is because I would like my engine to be able to handle per-project custom tags, such that a file can be parsed that describes a list of custom tags and their corresponding custom strings (defined by the user without knowledge or access to engine code) that they resolve into and will be placed in a std::map<string, string> example : "/goblin" = "/fgCyan GoblinName: /fgDarkGreen /bgWhite" Any ideas? Or is this impossible with a one liner? (like a cout statement?)
  5. Hi, In my game engine I output stuff for debugging purposes to the windows console using std::cout. I wanted to use colors so I can more easily oversee what is going on, as well as some "macros" using /tags. Let me show an example of what I am talking about: [CODE] myCout << "/warn Entity: "<< EntityName << "is doing /fgRed badstuff \n"; [/CODE] would output: [color=#8b4513]Warning: [/color]Entity: obj1 is doing [color=#ff0000]badstuff[/color] The way I have this is that I parse a stringstream.str() and send that string to my function that will format it and output it, but it currently looks like: [CODE] mysstream << "/warn Entity: "<< EntityName << "is doing /fgRed badstuff \n"; myCout(mysstream.str()); [/CODE] Obviously, I don't want to do this for every output, I want to use my output function just like std::cout, having the functionality of the same << operators, but does my formatting also. How could I achieve this? Your help is much appreciated!
  6. Hmm, the above example of a component based system really makes me confused as it completely goes against what I have believed component based design stand for. I thought that ideally there should be only 1 entity type, that doesn't differentiate between a weapon, a rock or a spaceship. I have also thought that the components should be mostly uniform, or at least to the entity (as to the entity the only interface open is Update() towards component). For example in your sample, what if that character system works for almost every character, but one guy is on fire and needs a particle emmitter component? Do you rewrite the whole CharacterEntities class and add a vector for particle emmitters, that won't ever be used on 99% of the characters, or do you accept the limitations of the CharacterEntities class and represent the flaming guy in his own class, as an exception? How about the player character? Should all characters have some function, or component vector for components that handle input, or playerCharacter needs a separate class? Or if you want to include a special weapon that works differently for every other one, should the whole Weapon class get rewritten because of it? I though things like these were the reason why game development started to shift towards component based design from object oriented. Please correct me if I am seeing this from the wrong perspective, or if my picture on component based design is wrong. This is what convinced me of redesigning my engine to component based: [url="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCwQFjAB&url=http%3A%2F%2Fwww.gdcvault.com%2Fplay%2F1911%2FTheory-and-Practice-of-the&ei=a-GUT-ziHISViQKJ3-CKDw&usg=AFQjCNGVTFg3QbWsg62Hqimepl-bQB1LaQ&sig2=66hmtDj-ZFYrhDvX5GtMNw"]GDC_Powerpoint_OOvsComponentOriented[/url]
  7. Thanks for your reply adam4813, I have a similar idea on the design of my system, although with mine Entities do actually get to call each component's Update() function, but that only does the general logic. Graphical components further need to be processed by the GraphicsManager, that has access to more functions than Update() (Render for example). Colliders position and transformations get updated by the Entity, but it will be the CollisionManager that will check for actual collision and send out events. Most of this is still only on paper, so it might turn out to be better to separate all functionality from entities, I'll see what happens. [b]Another Question:[/b] When I am trying to handle events, such as an KeyboardInputComponent maps a key to an event. For example: (I'm doing this in SFML2) std::map<sf::Keyboard::Key, String> inputTable if any of the keys on the map are pressed, send an eventMessage to the evenChannel, such as if (sf::Keyboard::IsPressed(sf::Keyboard::Space)) sendEvent("Fire"); The eventHandler will decide what to do with "Fire". What I would like though is that I can work with all events being human readable strings, but I don't want the program to actually be comparing strings because it is probably inefficient. Also, I want this in a way that the event words wouldn't need to be hardcoded into the engine, it could be parsed from an xml or txt file, and a new event could be generated even during runtime. How can I make this work, so it would work like enums (without always having to extend the values inside the enum if I want to extend it), so I work with readable words, but the program deals with more computer-friendly data. Would I also use 2 maps, one as String->Int and another for Int->String? When I add the event by string it would only put the corresponding int ID on the event channel, and when the eventHandler checks for events by string it would get the corresponding int ID?
  8. I have thought of the update priority and figured that each component has an int priority, and the entity's component list is sorted by the component's priority. I thought it wouldn't be inefficient since it only needs to be sorted when a new component is added. If I wouldn't have a BaseComponent class, then I would need to change the Entity class whenever I would come up with a new Component type, so it has a corresponding container. Do you mean the entities should do all the processing of components without the need of Managers? That's how I tried to do this first, but when I got to collision I thought I really need an external manager that oversees every entity's every collider, and thought of using a GraphicsManager would also be useful. Or am I only supposed to use a handful of core component types without a lot of inheritance? For example I have: GraphicsAnimSprite---->GraphicsSprite------->GraphicsComponent---->BaseComponent GraphicsParallaxSprite-^ Is that bad design, should I only have GraphicsComponent, and implement everything else from that without deriving classes? I would just like each entity to know about all its components, and I would like globally each manager to be able to iterate through a specific type of component of every entity. I am not sure how I can achieve this. Since I have many derived classes of components, I can only store vectors of pointers to base classes (either the root ComponentBase, or by family as GraphicsComponent, InputComponent, Collider). Sorry for all these questions, and my confusion, I am really new to component based design. Your help is much appreciated.
  9. Thanks a lot, this is very helpful! So, based on what you have suggested, if I understand it correctly, would it be a good design if: - I have a vector<std::shared_ptr<ComponentType>> globally, containing pointers to all components of a specific type that need to be accessed together by their managers, such as GraphicsManager for GraphicComponents, InputManager for InputComponents. - The owner entity has a vector<std::shared_ptr<BaseComponent>> containing a pointer to every component it has, without really knowing or caring about their type, since the entity will only call their general onUpdate() My concern about the above, maybe because of the lack of knowledge on std::shared_ptr: - Is that ok, that 2 shared_ptr point to the same entity, but by different type (one is BaseComponent, the other is GraphicsComponent)? - Will they still know about each other, counting their references, or like this they are separated, and each thinks they are the only one owning the component they point to? Also, so far the way I have my design is when a component is added to an entity, it is added to the entity's std::vector<std::shared_ptr<BaseComponent>> entityComponentVector. The component was created by std::shared_ptr<BaseComponent> (new ComponentType(...)). Each component has a onAddedToEntity() function, through which I would like to register the component by type to the corresponding global vector of pointers by component type. From inside the object, is there a way to pass the shared_ptr that owns it to the corresponding manager for the type so it gets registered? To give an example of what I want, I have an Entity as the player. To this entity I give a SpriteComponent, that is a GraphicsComponent derivative, and the way I add it is by pushing its shared_ptr<BaseComponent> to the player's componentvector, so it knows what it has. After the component has been added its onAddedToEntity() function should pass either [b]1.[/b] its owning shared_ptr<BaseComponent> to the GraphicsManager, that would possibly cast and use it as shared_ptr<GraphicsComponent> or [b]2.[/b] a shared_ptr<GraphicsComponent> of itself to the GraphicsManager. Again, I am not really sure how I can do this [b]EDIT: [/b]Maybe I am approaching this whole thing from the wrong direction, I am not even sure if it is possible to have it such that each entity has pointers to its components as well as each manager has pointers to components it needs, all stored in different vectors of pointers. Should there only be vectors of component types and a std::map, and managers access these vectors directly, while entities only know the indexes of the components they own, which they look up from the std::map? (I'll also use one of the methods for string <-> intID access, for now I don't really have more concerns about that as you have provided some very clear implementations)
  10. Hi, I am working on my component based engine, and trying to implement an entityID system. The way I am planning it is that each entity and component has a unique int ID and a unique string ID. I thought of two ways to implement this, but not sure which would be better: [b]1. Each entity has their own map.[/b] The entities are stored in a std::map<int, string> and components inside entities are also stored in a std::map<int, string> (there are multiple maps) [b]2. There is only 1 (or a fixed number of) global maps that resolves everything.[/b] The entities and components only contain an int ID, on creation their string ID is going to be added in a single global std::map<int,string> that will resolve any id access by string. (or perhaps 1 map for entities, 1 for components) For my peace of mind I would be more comfortable of knowing that all string IDs are stored in a single place, but not sure if it is a good idea, since it will take a longer time to search through a big global map to find a string. On the other hand, I would imagine entities would be called with their int IDs, and their string IDs would be used more for debugging, so it wouldn't make a big difference (I might be completely wrong on this one.) I would appreciate any suggestions on this. Thanks in advance! EDIT: Also, is it a good idea in general for each entity to contain a string id, or no, because it is inefficient?
  11. Thank you very much for your detailed answer and explanations. I think I have enough information now to start redesigning what I have, and when specific issues would arise I would come back for help. I'll also read through the relevant part of the book you suggested, and look through your engine and Unity 3D. I'll also keep DOD in mind, but I'm probably just going to focus on one thing at a time (transitioning and adapting to composition).
  12. Thanks! In this kind of hierarchy, should the parent and child know about each other's components in general, and work accordingly? I am just having trouble thinking out a general design that obeys the most important concepts of component based design: - Ideally all entities should be treated exactly the same (on the outside nothing knows or can know what components does the entity have) - Each component is capable of working completely independently without the assumption or knowledge of any other component within the same entity - Each component should still somehow be able to communicate with one another (or provide information that another entity if exists might make advantage of) For the communication, the way I picture it huge switch-case blocks will need to be used for the "just in case there is a xyz component in this entity". Is that how it should be? For the custom hierachy, when an entity is in Father-Child relationship, how does that affect the general operation? Does each component have to have a different set of switch-case statements in case the holding entity is a Child, or is a Father? Or should I use more specific single-purpose components, so I could use one that is making the assumption that the entity in which it will be used is a child or father to something? Wouldn't that however beat the purpose of the whole concept of nothing makes any assumptions?
  13. Thanks, I have actually just read this a few days ago, someone recommended it (DOD) to me as a better alternative to OOP design in game development. Definitely interesing, but I am starting to feel I have too much on my plate. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Could anyone please answer my previous question? I'd really appreciate it.
  14. In my inheritance based structure, I could have my ship entity that owns 2 wing entities that move and emit particles based on the ships velocity, and can own weapon entities, that are also animated, and can use auto targeting (turn toward and target the closest enemy). With component based design how is this implemented? Should the ship, wings, weapons be separate entities (each with its own set of components) that are tied together somehow, or I should just have my ship entity and the wings, ship weapons, wing weapons be components?
  15. Thanks for your reply. I found a pretty nice ppt from GDC showing how the development team transitioned from Inheritance based design (that they used for Hulk: Ultimate Destruction) to component based design (that they used for Prototype), and showing how component based design seems superior. [url="http://www.gdcvault.com/play/1911/Theory-and-Practice-of-the"]http://www.gdcvault.com/play/1911/Theory-and-Practice-of-the[/url] It doesn't really go into specifics however. Does anyone know of a good tutorial or project with some sample code that is built on composition?