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


  • Content count

  • Joined

  • Last visited

Community Reputation

159 Neutral

About bedtime

  • Rank
  1. [quote name='SiCrane' timestamp='1354075943' post='5004831'] [quote name='bedtime' timestamp='1354069769' post='5004793'] I've been at this for a day now and no progress. I read the article and I've still not got this other part of the code to work. [/quote] The purpose of the article is to get your code to compile and link when using multiple source and header files. Following those directions doesn't prevent other kinds of problems to show up in your code. If your code even gets to the point where it can run then your problem isn't related to the article. [quote]I appear to have an issue with my Map object not being being recognised even though i've declared it and its within the same class.[/quote] If it wasn't being recognized it wouldn't even compile. The fact that it does compile means that it is being recognized. Since the problem is a run time error when accessing the Map variable then most likely the problem is that you aren't initializing your object properly. If that isn't enough of a hint to get your program working properly, try producing a minimal, but complete code sample that demonstrates your problem. [quote name='RulerOfNothing' timestamp='1354070900' post='5004803'] Why do you have braces in the line: Map.insert({std::make_pair<int, int>(1, 2), gameObj1}); ? [/quote] That's a C++11 feature: uniform initialization. [/quote] Thanks. I solved it. It was something to do with dereferencing and not using 'new' to declare my game object. Sorry for my constant posts. Today has just been a frustrating day for me, much more then usual and I'm sitting here with a headache... I've been at this way too long today. Maybe 14 hours. Brain went to mush several hours ago. Anyways, you guys have all been so helpful.
  2. [quote name='RulerOfNothing' timestamp='1354070900' post='5004803'] Why do you have braces in the line: Map.insert({std::make_pair<int, int>(1, 2), gameObj1}); ? [/quote] I'm not sure how to get the code to work without them. I get a compile time error. I just tried changing the code to: [source lang="cpp"]getMap()->insert(std::make_pair(std::make_pair(1,2), gameObj1)); [/source] its okay just inserting the once, but if I repeat the code above or try to access getMap() again it seg faults.
  3. Edit, still not working... sigh I've been at this for a day now and no progress. I read the article and I've still not got this other part of the code to work. I appear to have an issue with my Map object not being being recognised even though i've declared it and its within the same class. I've tried the map object as a pointer as suggested in the link (its not a pointer because i dont feel like changing all the other stuff around by adding the arrow insertion operator for the 5th time.... Pointer or not both result in seg faults. Out of everything in c++ these cyclic dependancies are the holding my code back the most. This is really quite frustrating. The article said in 99% of cases adding a forward declaration and pointer to object of another class is enough. I'm missing something. Here is the code: [source lang="cpp"] // game.h #ifndef GAME_H #define GAME_H #include <map> #include <vector> #include "staticcount.h" #include "value.h" #include "tvalue.h" class GameObject; typedef std::pair<int, int> Key; class Game { Value value; std::multimap<std::pair<int, int>, GameObject*> Map; std::multimap<std::pair<int, int>, GameObject*> go2; // x chunk, y chunk, gameObject std::multimap<int, std::multimap<int, GameObject*>*> go; public: Game() { value.newNum("game number", StaticCount::getNumGames()->getNum()); } // get game values Value* val() { return &value; } void loop(int x_begin, int x_end, int y_begin, int y_end); std::multimap<std::pair<int, int>, GameObject*> getMap(); }; #endif[/source] [source lang="cpp"]// game.cpp #include <iostream> #include "game.h" #include "gameobject.h" #include "keys.h" std::multimap<std::pair<int, int>, GameObject*> Game::getMap() { return Map; } void Game::loop(int x_begin, int x_end, int y_begin, int y_end) { /* uncommenting the line below makes the code below works but its useless as it goes out of scope and is not stored. if the line is commented i get a seg fault */ //std::multimap<std::pair<int, int>, GameObject*> Map; GameObject* gameObj1 = new GameObject; gameObj1->val()->setNum("test", 10); // seg fault is from the line below: (this works if above code 6 lines above is uncommented) Map.insert({std::make_pair<int, int>(1, 2), gameObj1}); std::cout << "made this far" << std::endl; GameObject* gameObj2 = new GameObject; gameObj2->val()->setNum("test", 20); Map.insert({std::make_pair<int, int>(3, 4), gameObj2}); GameObject* gameObj3 = new GameObject; gameObj3->val()->setNum("test", 30); Map.insert({std::make_pair<int, int>(5, 10), gameObj3}); x_begin = 2; y_begin = 1; x_end = 5; y_end = 9; x_end++; y_end++; // if (x_end <= x_begin) return; // if (y_end <= y_begin) return; Key lower(x_begin, y_begin); Key upper(x_end - 1, y_end); auto first = Map.lower_bound(lower); auto last = Map.lower_bound(upper); for (auto itr = first; itr != last;) { int x = itr->first.first; int y = itr->first.second; if (y < y_begin) { itr = Map.lower_bound(Key(x, y_begin)); } else if (y >= y_end) { itr = Map.lower_bound(Key(x + 1, y_begin)); } else { std::cout << "x: " << x << " y: " << y <<" test: " << itr->second->val()->getNum("test") << std::endl; ++itr; } } } [/source]
  4. [quote] If what you want to do is to do some operation on every element with x_begin <= x < x_end and y_begin <= y < y_end, one way to do that would be like: [code] typedef std::pair<int, int> Key; typedef std::multimap<Key, GameObject *> Map; template <typename Operation> void loop(const Map & map, int x_begin, int x_end, int y_begin, int y_end, Operation operation) { if (x_end <= x_begin) return; if (y_end <= y_begin) return; Key lower(x_begin, y_begin); Key upper(x_end - 1, y_end); auto first = map.lower_bound(lower); auto last = map.lower_bound(upper); for (auto itr = first; itr != last;) { int x = itr->first.first; int y = itr->first.second; if (y < y_begin) { itr = map.lower_bound(Key(x, y_begin)); } else if (y >= y_end) { itr = map.lower_bound(Key(x + 1, y_begin)); } else { //do whatever operation(*itr); ++itr; } } } [/code] [/quote] Thank you so much for taking the time to type that up. This was exactly what I was looking for; iterating within a range of x/y chunks. Took me a few times reading it over to understand most of what's going on. One thing that puzzles me is the operator input within the parameters. I'm not entirely sure how to supply that parameter input or what it does. If I had to guess its something to do with iterating... I noticed you left out the 3rd parameter in the for loop and incremented it within the loop below the 'operator'. Looks intriguing. Could you explain this? Also, I see you made map a const in the parameters. Was there a reason for that? I'm likely going to be changing some object within the loop if that's advisable to do. Once again, I really appreciate you taking the time write all that out for me. [quote name='Servant of the Lord' timestamp='1354046856' post='5004646'] Are chunks are composed of tiles? Or objects?[/quote] Objects. Each x/y map cooridinate is loaded with a GameObject which stores the 'components' such as rendering values and instructions for that specific character, the character itself, and sound components...[/quote] [quote]Have you actually tried just making a grid of uniform chunks, and actually seeing if it's too slow for your program?[/quote] Yes, I had started out with a vector tile-based situation. I profiled it (bare text run, no graphics), testing it with various chunk sizes and getting best performance at around 250 - 500 fps. This was with little characters on the screen and no AI, graphics, at all yet. More characters slowed it right down, 25 - 100 fps. Just not cutting it. I then profiled a system based on a 'list' of airborne x/y chunks, which only had chunks that held objects, and fps went to 4000 -10000 fps. When I first jumped I thought it was broken because I couldn't see the character jump! [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] When I loaded the board and level with characters, massively, it still did 150 - 500 fps, which was good enough. [quote]So you break your world into 'chunks'. World has a [b]grid [/b]of [i]smart pointers[/i] to Chunks (yes, a grid). Each location on the grid can either be a null smart pointer (thus saving you your precious memory [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]), or can have a smart pointer to a valid Chunk.[/quote] I like the smart pointer idea and I like the idea of maybe using something to say if a character is enabled or not. Objects not enabled could be used as pooled objects, which is fine. By 'chunks' I see you mean a 'grid' but I do not want a tile-based grid. I'd rather a list (map, vector....whatever container) 'within' a chunk. So anything on that list that is processed if that chunk is on the screen. [quote]A chunk is just a "bucket" of entities. Any solid who's center is over the chunk's boundaries, belongs to that chunk. A Chunk:[list] [*]Manages it's own loading and saving from file. [*]Tells the Objects within it to draw, think, etc... [*]If an Object Entity walks off of one chunk, that chunk passes ownership of that object to the next chunk.[/qoute] [/list] I'll take a look at your code. I'm thinking of maybe having an outside entity control the chunks. As for objects changing chunks, you've described it exactly how I had it before; objects swapping memory positions to different containers. As well, leaving a pooled disabled object in its tracks to be used later. [quote]Maybe you want to specify to only keep an object in memory if it's within a certain range.[/quote] That's a good idea. Perhaps a small loop that runs a list of these characters and runs an update() with full or high range chunks. But that's a while away. [quote]Let's convert this directly to pseudo-code: [code]Object { Position IsPersistent RangeToKeepInMemory //The distance away the player needs to be before it is destroyed. bool SaveStateWhenDestroyed() -> (IsPersistant && hasChanged) bool KeepInMemory(playerDistance) -> (playerDistance > RangeToKeepInMemory) Save() Load() Draw() Update(deltaTime) //Think, animate, etc... } Chunk { Vector<Object::Ptr> Objects StreamOut() //Unloads all objects except those it needs to keep in memory. StreamIn() //Loads all persistent objects, like walls and enemies that don't spawn but have preset locations like bosses. Draw() -> Draw every object Update(deltaTime) -> Update every object } World { Grid<Chunk::Ptr> Chunks; LoadNewWorld(); StreamChunksAround(location); Draw() -> Draws all chunks nearby. Update(deltaTime) -> Updates chunks (which in turn updates objects) }[/code] This can be improved upon, but it's a good start and really straightforward and simple. It also does not waste much memory or speed. You can steal my C++ [url="http://pastebin.com/rJv7PVxm"]Grid class here[/url] - re-sizable and permits negative indices. If you know the size of your World ahead of time, and it doesn't change during the course of that play, you could use a std::vector of size (width*height) instead. The whole map<map<Object>> thing just doesn't seem like good design. [/quote] Thank you for all that info! I'll take a look at your Grid class tomorrow when my mind is more agile and has had some rest. Been at this all day. Negative indices and resizable definately sounds good. It's just what I need.
  5. [quote name='Servant of the Lord' timestamp='1354041845' post='5004607'] Let's step back a second. What are you actually trying to do? Not, "how are you trying to implement it", but what is your overall design problem you are solving? Do you have a grid of spaces, and a game object might be on that grid? [/quote] I'm making a mario-style side-scroller. My map is made up of x and y chunks, but it is not a grid. They are more like a list of chunks. This way I can skip chunks (or sections, whatever you want to call it) for areas that don't have any objects. So this is not tile-based. I would like to make a board map that is speed and memory efficient that can do positive and negative chunks. This is important because I want the map to be realtime expandable during runtime. There will be a lot of objects in the game so I want to be able to focus on only displaying the very minimum. There may be more then one object on the same chunk as well, hence the multimap. Levels might just go up 0 degrees. They might go backwards (270 deg). They might 'squiggle' or go in a circle. I've done this all before but only with an X chunk and not with a Y chunk as well. So the map was only cut into X sections which led to inefficiencies if the level went straight upward. Since then I've since learned some new concepts such as component/entity programming so I'm changing things up and starting over.
  6. [quote]Congratulations, you've re-implemented std::pair<int, int> ... incorrectly. For an operator < overload to be valid for use in a std::map or std::multimap it needs to be a strict weak ordering. Some of the qualities of a strict weak ordering are irreflexivity (x < x is false), antisymmetry (if x < y then y < x must be false) and transitivity (if x < y and y < z then x < z). You've got these three. However, the last quality of a strict weak ordering is transitivity of equivalence (also called transitivity of incomparability). Under a strict weak ordering, two objects x and y are equivalent if x < y and y < x are both false. With transitivity of equivalence if x and y are equivalent and y and z are equivalent then x and z must be equivalent. Here your operator < fails. With your function (1, 2) and (3, 2) are equivalent and (3, 2) and (3, 4) are also equivalent. However (1, 2) is less than (3, 4). One way to fix it is to change your operator < implementation: [code] bool operator<(const Keys &right) const { if (key1 < right.key1) return true; if (key1 > right.key1) return false; return key2 < right.key2; } [/code] Or you could just use std::pair<int, int>.[/quote] Thank you so much for that explanation. Now I know. [quote]Also, it's kind of pointless to create getters for public member variables.[/quote] Lol, yeah. I noticed that too. I'm so used to declaring class variables private and making a get function for it... Why stop now?? [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] [quote]What do you mean by "iterate in ranges"? [/quote] I want to be able to do something like this: [source lang="cpp"]void getXY(const int& x, const int& y, const int& xRange, const int& yRange) { // pseodo code: for(it = xlow; it != xhigh; ++it) for(it2 = ylow; it != yhigh; ++it2) // do something }[/source] This way I can print out only certain x/y chunks whilst in my game. If std::pair<int, int> works thats great but I don't know where to find a good tutorial or an example.
  7. [quote name='SiCrane' timestamp='1354027753' post='5004527'] A composite key would be instead of using a multimap with an int key containing multimaps with int keys, instead use a single multimap with a key that contains two ints like a std::pair<int, int> such as std::multimap<std::pair<int, int>, GameObject *>. [/quote] This sounds like a great idea and I don't want to keep bugging you for examples. Is there perhaps a good tutorial on this? I have several C++ books but they don't seem to go this in depth. If you can recommend a book that will help me with this I'll read it. There seems to be a another way. That is to use a Key class to store the keys. How does that compare to using a 'pair' of keys? Here's what I have played with so far ('val' is encapsulated code that allows me to store to that object and test it): [source lang="cpp"]class Keys { public: Keys(int k1, int k2) : key1(k1), key2(k2) { } bool operator<(const Keys &right) const { return (key1 < right.key1 && key2 < right.key2); } const int getKey1() const { return key1; } const int getKey2() const { return key2; } int key1; int key2; } [/source] [source lang="cpp"] std::multimap<Keys, GameObject> go2; GameObject* gameObj1 = new GameObject; gameObj1->val()->newNum("test", 10); go2.insert(std::pair<Keys, GameObject>( Keys(1, 2), *gameObj1) ); GameObject* gameObj2 = new GameObject; gameObj2->val()->newNum("test", 20); go2.insert(std::pair<Keys, GameObject>( Keys(3, 4), *gameObj2) ); GameObject* gameObj3 = new GameObject; gameObj3->val()->newNum("test", 30); go2.insert(std::pair<Keys, GameObject>( Keys(1, 2), *gameObj3) ); for(auto& i : go2) { std::cout << "x: " << i.first.getKey1() << " y: " << i.first.getKey2() << " test: " << i.second.val()->getNum("test") << std::endl; } [/source] The above code seems to print out the results just fine, but I question how easy it'll be to get this to iterate in ranges. I do think it might be nice as it would allow multiple ways to sort but I'm new to all this.
  8. [quote name='Servant of the Lord' timestamp='1353968349' post='5004335'] When doing containers within containers, it helps to typedef them (if it makes sense in whatever context your code is in). [code]typedef std::multimap<int, GameObject*> GameObjectMap; std::multimap<int, GameObjectMap*> gameObj;[/code] Second, you 'new' a GameObject, but call it 'tempObj'. A [b]new[/b]'d variable is definitely not temporary. Anything you [b]new[/b] [u]must[/u] be [b]deleted[/b]. [u]Your map will not delete it for you[/u]. Likewise, following SiCrane's suggestion, you need to remember to delete any [b]std::multimap<int, GameObject*>[/b] you new. If you use smart pointers, the smart pointers will delete the memory for you - but as it stands, you'll have multiple massive memory leaks (depending on the number of GameObjects and how hefty they are). I like to typedef my smart pointers within GameObject class itself, so I can use [b]GameObject::Ptr[/b] instead of [b]std::shared_ptr<GameObject>[/b]. This will result in code that looks like this: [code]typedef std::multimap<int, GameObject*> GameObjectMap; std::multimap<int, GameObjectMap> gameObjects; gameObject.insert({1, {1, std::make_shared<GameObject>(...arguments for GameObject constructor...)}}); [/code] [/quote] Thank you for this info. It's embarrassing how neglectful I've been with deleting my 'new' objects. I also for some reason thought that when the object went out of scope it was delete automatically but after hearing you and reading a little it isn't. A good find here. As far as smart pointers I, they seem like a lazy way to do things but perhaps that's perfect for me for now. [quote]A multimap inside a multimap sounds like quite the hairy data structure, not to mention the extra memory management you incur by having the outer multimap store pointers to the inner multimaps! You could accomplish the same thing with a single multimap to your objects and a composite key[/quote] A composite key? I don't think I've heard of this before. I've just dabbled into this on google and it looks like I have a little reading to do, thanks.
  9. [quote name='SiCrane' timestamp='1353966473' post='5004325'] Your multimap has a pointer to a multimap as the value, so you need to pass a pointer when you insert into it. Probably by using new to allocate a multimap. So something like: [code] gameObj.insert(std::make_pair(1, new std::multimap<int, GameObject *>())); [/code] [/quote] Thank you. Worked perfectly! Here's what I did: [source lang="cpp"] std::multimap<int, std::multimap<int, GameObject*>*> go2; std::multimap<int, std::multimap<int, GameObject*>*>::iterator it1, itlow1, ithigh1; std::multimap<int, GameObject*>::iterator it2; // just return first result (better used with map than multimap) it1 = go2.find(x); it1->second->find(y);//->second; // inserting a new object go2.insert(std::make_pair( 1, new std::multimap<int, GameObject *>() )); // make object to insert std::multimap<int, GameObject*> gameObj; GameObject* insertedGameObject = new GameObject; // inserting object gameObj.insert({ 1, insertedGameObject }); go2.insert(std::make_pair( 1, &gameObj )); itlow1 = go2.lower_bound(x); ithigh1 = go2.upper_bound(x); // interate through all uppper/lower x/y values for (it1 = itlow1 ; it1 != ithigh1; ++it1) { for (it2 = it1->second->lower_bound(y); it2 != it1->second->upper_bound(y); ++it2) { // do something } }[/source]
  10. I've looked around and can't seem to find the answer. Here is my multimap and an attempt at my idea of what I want to do: [source lang="cpp"] // declared multimap of x/y/object std::multimap<int, std::multimap<int, GameObject*>*> gameObj; // pseodo code of what I want to do: GameObject* tempObj = new GameObject; gameObj.insert({ 1, { 1, tempObj });[/source] Any ideas?
  11. [quote name='SiCrane' timestamp='1353774940' post='5003768'] You might want to read this article: [url="http://www.gamedev.net/page/resources/_/technical/general-programming/organizing-code-files-in-c-and-c-r1798"]Organizing Code Files in C and C++[/url]. You have problem number two from that article. [/quote] Thank you so much for the quick response! I read and found the answer. Excellent article. I found the issue and fixed it. Here is the advice for anyone that might want a quick glimpse at the answer: [i]quoted from article[/i] [quote]There are more in-depth ways of resolving cyclic dependencies, but they are beyond the scope of this article. In 99% of cases, using forward declarations and favoring normal functions in C./.CPP files over inline functions in header files will be enough.[/quote] Working code: [source lang="cpp"]#ifndef GAMEOBJECT_H #define GAMEOBJECT_H #include <iostream> #include <vector> #include <string> //#include "component.h" class Component; class GameObject { std::vector<Component*> components; //A list of components attached to the game object public: std::string name; //The unique name of the game object //Transform transform; //The object's transform //Initializing Ctor GameObject(std::string Name = "Default Player") : name(Name) { } ~GameObject() { } //Finds the attached component with the name Name (if it exists) /* Component* GetComponent(std::string Name) { } //Finds the attached component with the index Idx (if it exists) Component* GetComponentAt(int Idx) { }*/ //Attaches a component to the game object void AddComponent(Component* NewComponent) { components.push_back(NewComponent); } //Detaches the component with the name Name (if it exists) void RemoveComponent(std::string Name) { } //Detaches the component with the index Idx (if it exists) void RemoveComponentAt(int Idx) { } //Initializes the game object by initializing each of its attached components void Start() {} //Updates the game object by updating each of its attached components void Update() {} }; #endif // GAMEOBJECT_H[/source]
  12. I seem to run into this issue where I try to use seperate file compilation and I end up getting the message: [quote]error: ‘Component’ was not declared in this scope[/quote] I've declared the Component file, but I think this is a cyclic issue of some sort. Is there a way that I can avoid this problem? Here are the files: [source lang="cpp"]// main.cpp #include <iostream> #include <string> #include "gameobject.h" #include "component.h" int main () { GameObject* go = new GameObject("Player"); Component* gun = new Component; go->AddComponent(gun); } [/source] [source lang="cpp"]#ifndef COMPONENT_H #define COMPONENT_H #include <iostream> #include <string> #include "gameobject.h" class Component { public: std::string name; //The name of the component bool enabled; //Is the component currently enabled? GameObject* gameObject; //The game object that owns this component int type; //The type of component //Initializing Ctor Component(std::string Name) : name(Name), enabled(true) {} //Dtor virtual ~Component() {} //Abstract function, called when the scene is started virtual void OnStart() = 0; //Abstract function, called when the scene is updated virtual void OnUpdate() = 0; }; #endif // COMPONENT_H [/source] [source lang="cpp"]#ifndef GAMEOBJECT_H #define GAMEOBJECT_H #include <iostream> #include <vector> #include <string> #include "component.h" class GameObject { // ERROR STARTS AT CODE BELOW (notice 'component.h' is declared above): std::vector<Component> components; //A list of components attached to the game object public: std::string name; //The unique name of the game object //Transform transform; //The object's transform //Initializing Ctor GameObject(std::string Name = "Default Player") : name(Name) { } ~GameObject() { } //Finds the attached component with the name Name (if it exists) /* Component* GetComponent(std::string Name) { } //Finds the attached component with the index Idx (if it exists) Component* GetComponentAt(int Idx) { }*/ //Attaches a component to the game object void AddComponent(Component* NewComponent) { components.push_back(*NewComponent); } //Detaches the component with the name Name (if it exists) void RemoveComponent(std::string Name) { } //Detaches the component with the index Idx (if it exists) void RemoveComponentAt(int Idx) { } //Initializes the game object by initializing each of its attached components void Start() {} //Updates the game object by updating each of its attached components void Update() {} }; #endif // GAMEOBJECT_H [/source]
  13. I've looked into Cistron and while it looks awesome and seems to be what I'm looking for I have a tr1 compatibility issue in Linux so it's useless to me unless I can find a way to install. A bug report was sent about a year ago on the issue. Seems to be a Duke Nukem forever sitation. Apart from that I've spent days trying to fingure out how to use pure virtual functions without issues and it's becoming frustrating. I'm doing something wrong. Anyways, starting from scratch again... If anyone knows of a really simple example with all files included (main as well) and without SDL included I would be grateful. At this point I'm just causing myself a headache. Sorry to sound so bummed.
  14. [quote name='uglybdavis' timestamp='1353521782' post='5002966'] There is no right or wrong answer. Whatever makes sense to you is the right way. Do it, and learn from your mistakes. With that being said, i think your idea of composition is a little too textbook (Personal opinion). Maybe look at some tutorials of what other people are doing. I think this one does a good job of showing how you can use composition in a 2d engine (Obvious issues with the code, but you should be able to work past that) [url="http://www.inverted-keystrokes.com/2012/02/11/2d-game-engine-tutorial-component-based-entity-systems/"]http://www.inverted-...entity-systems/[/url] It's worth reading all the posted parts of the tutorial. [/quote] Thank you so much for that link. I've read the article and have been implimenting the changes. It took me a couple reads to understand what was going on but I finally get it. I wanted to make sure I understood before I replied again. [quote name='BeerNutts' timestamp='1353531956' post='5003020'] I've been into CBES (Component-Based Entity Systems) for a while. What you have would not be called a CBES. You're Character Object is a traditional object which has defined parts to it. Rather, you should have a totally Generic Entity which hold different components types, like: Player: This Component is what makes your Player be the Hero. Animation: This defines how your player animates based on the Player's State PhysicalObject: This is what holds all the physical properties of your player; Location, Velocity, Mass, Size, etc. Weapon: This handles the weapon the player uses etc. Then, there are 2 schools of though on how to control the component; One if the components have all the logic in them, but this requires communication between components (ie, the Weapon Component needs to know where the player is in the world from the PhysicalObject to fire a bullet form that location). It's doable (see my Journal for examples), but I believe I prefer the 2nd method You can also have the components ONLY hold data, and design Systems that act on and modify the data. So, you would have a Weapon System that gets updated with the entity, and it handles firing the bullet for any entity that has the Weapon component. You are welcome to look at my Journal (link in my sig) as I've detailed both methods of CBES. It takes a bit to get your head around to really thinking in Components making up the entities, but once you do, you'll be able to see the benefits. BTW, [url="http://blog.wujitouch.com/post/ComponentEntity-System-Frameworks.aspx"]here's a link[/url] to some articles about Entity Systems, and links to some externally developed Entity Systems [/quote] I used information from uglybdavis's link and now there is a generic entity. As for the controlling components I am likely going to go with components only holding the data and being modified by another system. I haven't yet looked at your link, but I will. This is kinda information overload for me ATM as I'm new to this. I do see the results already. It's so much easier to make changes. The classes are much smaller and easier to manage. And I've made a number class and point class that have made great use of reusing code and go by the philosopy 'do one thing and do it well'. I much prefere this approach.
  15. [quote name='kd7tck' timestamp='1353489255' post='5002870'] keeping track of limbs might be too much. Just use sprite sheets and animate that way, simple sometimes is better. [/quote] Thanks. I havent used a graphics program yet so I didnt know this. Though I question if they will allow the same kind of flexibility and options I'm getting right now. All, No other comments? I assume I'm way off base here when I don't get replies.