   SDL game/engine?
  hello, forum!i've started to create a game some weeks ago, and i already have a similar post here, but i didn't get too much answers, so sorry for reposting.okay, so my idea was at first, to create a game (a 2d platform shooter) and i've written some code (mostly based on lazy foo's sdl tutorials). then, a day or two before, i realized that my code was ugly and i started to rewrite it. now i have some better structured code but i still need some help in a lot of things. it looks that i can reuse the whole thing later, so it would be important for me to get some things work.first, loading things (other than saves and maps). if i'd write particles like this (from lazy foo's):Particle::Particle( int X, int Y ){    //Set offsets    x = X - 5 + ( rand() % 25 );    y = Y - 5 + ( rand() % 25 );   //Initialize animation    frame = rand() % 5;   //Set type    switch( rand() % 3 )    {   case 0: type = red; break;   case 1: type = green; break;   case 2: type = blue; break;    }}it would work only with three kind of surfaces. how can i make it so when i start writing the game, i can create particles of many surfaces without changing the code in particle.h or whatever is it in?second, tiling. i get the idea of it, but i have the same problem with it as with particles. i know these are just lazy foo's examples, but i haven't got too much idea of implementing them a different way. i accept any kind of tutorials or example code about them.third, a jumping character, and 2d physics. i don't want it to have complicated physics, just objects falling down from air. i could use some example code here.what i've created so far is athttps://sourceforge.net/projects/yolane/please give me suggestions!   
  Some comments on that particle constructor: don't randomize it's position in the constructor itself. That may seem to be a good idea right now, but it'll make your particle class less flexible. How to deal with particles that have to be at the specified position? Or particles that need a bigger spread? Instead, just use the specified position, and let the code that generates particles do the randomizing.Same goes for materials or textures: pass those as arguments to the constructor, and let the particle generator select the materials.As for tilemaps, a tilemap class would just hold a list of textures/tile images, and a 2D array of indices into that list. A level-loader function would then construct a tilemap object based on data read from a file (or from some other source).As for falling objects, just apply a gravitational force to them. That is, every object would have a position and a velocity. The gravity pull would simply alter the velocity of an object.So:Vector2 gravity = Vector2(0, 9.81);class FallingThingie{    Vector2 position;    Vector2 velocity;    public void update()    {   position += velocity;   velocity += gravity;   // You may want to limit an objects speed, which can be done by   // capping the length of 'velocity'.    }}EDIT: Just read through some of your code.For world coordinates, don't use integers, use floats or doubles instead. You can always convert them to integers when you need to, for example when rendering them.Don't store speed as a separate variable - the length of your velocity vector is the speed.You may want to give those structs some member functions to make them easier to work with: for example, a collidesWithBox() and containsBox() function for the collision box class. And for a position class (Vector2), some overloaded operators (+, -, +=, -=, *, /) would make using them quite easy.I wouldn't put that Control struct inside your Object class, either: an object should ideally have no notion of how it is controlled. Baking it in will only make such an object less flexible - at best it's dead weight.Move those velocity and collision box structs out of the Object class - they are useful for other purposes as well. Personally I'd call them something like vector2 and rectangle, and I'd specify their specific purpose inside the Object class with the variable names instead (Vector2 velocity; Rectangle collisionBox;).Read up on initializer lists. You may also want to read up on copy constructors and assignment operators.Wrapping namespaces around classes is... peculiar. I would only use them in large projects, to group related classes together, and this isn't a large one. It only seems to make your code harder to read here (Object::Object::Object?!).For font qualities, use an enum instead.[Edited by - Captain P on April 10, 2010 7:15:14 AM];  thanks for the advices, i'm gonna make the changes. how do you mean an objects shouldn't have notion of how it is controlled? i mean how would it move then? edit: and also what should i do with copy constructors?[Edited by - sandorlev on April 11, 2010 9:28:20 AM];Quote:Original post by sandorlevhow do you mean an objects shouldn't have notion of how it is controlled? i mean how would it move then? Some other code would tell the object to move. With a player-controller object, you would have some code that listens for input and based on that, it will move the player object. Enemy objects would be moved by AI code. But the objects themselves don't need to know about that - they just need to provide some functions by which they can be moved.Quote:edit: and also what should i do with copy constructors?Just read up on them, so you know where and when they need to be used, and how. Like constructors and destructors, a default implementation for the copy constructor and assignment operator will be created if you don't provide one yourself. For most cases (POD types, that is, Plain Old Data) that is fine, but as soon as you start to dynamically allocate things inside a class, things can subtly go wrong.   ;  sounds good. i've rewritten my code so it now uses initializer lists. another thing i've done is managers. i've created manager classes which manage loading and destructing data.they work like this:Texture::TextureManager tm;Texture::Texture* texture = tm.loadTexture("example.jpg");tm.removeAllTextures();what do you think about it?i keep namespaces because they separate stuff. like idon't want the monitor's default width to be mixed with something other's.   ;Quote:what do you think about it?I question designs that rely on "manager" classes. Such a design reflects notions of a people hierarchy. It suggests that the designer had no underlying design, so copied what seemed a good alternative, which is how people work. Your manager class is an arbitrary collection of work. Why does the class exist? Only to group together functions.If you think otherwise, you should be able to clearly explain the underlying model that you have created with pen and paper.   ;  it keeps track of every texture loaded with it so they can be cleaned up easily. i don't understand what's the problem with it.   ;  The name "Manager" for some conjures up images of singletons and big ugly monolithic classes that do far more than they should. In particular, "Managers" are prime candidates for violating the Single Responsibility Principle (see link in sig). Basically, you want a class to only be doing a single conceptual chunk of work.You might be better off calling it TextureLoader, or Texture::Loader, as long as you're using namespaces. If you're going to cache textures so you only have to load them once, you might want to delegate that to an internal TextureCache, but that might be overkill, at least for now. The idea is to keep all your classes fairly small and manageable.   ;  okay, so let me clear this manager stuff (or fontloader):it's a class which has a private list of fonts. its loadfont method adds every font loaded with it to the list before returning them. that way, at the end of the program, they can be easily closed by calling closeallfonts(). or, if it's needed to close one before the end, it can be closed by closefont(font). it does no more and no less.i'm sure i want to use this kind of class in my game, it makes it much easier to manage loaded data (eg. i don't have to call sdl_freesurface() for like 20 times in the end). what i'm asking is, would it be a good idea to include it in my "engine" (which is basically all the stuff i think is reusable in the game)?   ;  Caches and loaders fit well within a framework, yes - when designed well, they're easy to reuse and do make things easier to work with. I used to call these 'managers' as well, but as the others have pointed out, 'manager' is a rather generic term, so more specific names are better.I wouldn't use a list under the hood, though - a dictionary that maps filenames to resources makes it easier to check what resources have been loaded already.   