   Engine Design - characters
  I'm writing a 2d game engine and I'm at a point where i want to create characters from sprite objects, seems pretty straight forward, right?I'd like to get an opinion on 2 possible designs here.One design involves having an undefined function in place for each direction the character can move, for example MoveLeft, MoveRight, etc..However, I've also considered simply having a call to one function with a variable of some sort that indicates the direction in which I would be moving. So 1 function would be broken into 4 sections, up/down/etc..and the variable would direct which 'section' gets execution, similar to a switch statement.Thoughts?   
  definately solve this problem using math/logic rather than hard-coding that type of function.you're probably representing your object's position with a point, along the lines of this simplified 2D example:Position.X = 10Position.Y = 10so, make a direction vector like:Direction.X = -1Direction.Y = 0then, add the two together for a move, like:Position.X = Position.X plus Direction.XPosition.Y = Position.Y plus Direction.Yif all worked correctly, the position is now:Position.X = 9Position.Y = 10In summary, using this type of logic is a much better way to go in terms of flexibility, maintainability, understandability, and any other ibilities I might be forgetting atm ;-);  Ok, and what about things such as sprite changes that occur with going right/left?I would have to have some sort of function that questions the direction direction im facing and update the image appropriately, no?Just to play devils advocate here, in most engines I've played with in the past, I've seen the suggestions similar to what I posted. Now, just for the record, of the 2 methods I posted, which do you think would be the better of the two?;  The implementation he suggested is closest to your second option, having one function that that was called with some kind of direction flag.  However, he suggested something more flexible.  whats wrong with having just one general move function, instead of 4 or 8 different functions.//IE:void GameCharacter::move(int dX, int dY){    x_pos += dX;    y_pos += dY}What's best for your specific implementation is up to you, you're the one who is working on it.   ;Quote:Original post by zerothrillzThe implementation he suggested is closest to your second option, having one function that that was called with some kind of direction flag.  However, he suggested something more flexible.  whats wrong with having just one general move function, instead of 4 or 8 different functions.//IE:void GameCharacter::move(int dX, int dY){    x_pos += dX;    y_pos += dY}What's best for your specific implementation is up to you, you're the one who is working on it.I think he's talking about different visual representations of the sprite depending on direction of motion. You could hardcode that, or you could do something like store a map of directions to sprite images in your character data files (assuming you use them). Then you just read this map in at runtime and use it to determine the correct sprite representation for each direction. This would be much more flexible and extensible.   ;  I think the second option is better.and for sprites change.I suggest you to use a map to index the sprite.if (speed.x > 0)    direction |= DIR_RIGHT;if (speed.y > 0)    direction |= DIR_DOWN;... m_SpritesMap[direction]->render(x,y);I write a class StateAnimation in my game project. and use id/string to index sprites to render. use a pointer to cache the most recent sprite to make indexing faster.Hope it helps. ;  When looking at the whole picture, then there are more than a single stage involved.Is the motion restricted, e.g. in a tile based game where the character can just move from one tile center to the center of neighbouring tiles? Or are the locations and/or orientation free? Is it a point-and-click interface for the PC? Is the AI enabled to drive NPCs to distant goals?The above questions involve the path-finding and obstacle avoiding. I.e. motion planning already depend on the motion capabilities, and its output (path segments) must consider the capabilities.Next, the motion along the path has to be performed, e.g. the character is currently "where on which path segment". From this the current direction and remaining motion distance up to the next path node (as a temporary goal) can be computed. The motion speed may be influenced by the remaining distance.Next, the animation system uses the current direction and selected speed (and perhaps the remaining distance) to drive the outfit and translation of the sprite. It may update the current location of the character as well; in this way an animation driven feedback can be realized, e.g. for better looking accelerations.The course overview above shows that something like a direction of the character may be passed through several stages. Writing a distinct set of functions for each stage would be cumbersome, and also would introduce hardcoded motion capabilities all over the place. Hence, as the other posters have already written, use a data driven approach instead.   ;Quote:Original post by zerothrillzThe implementation he suggested is closest to your second option, having one function that that was called with some kind of direction flag.  However, he suggested something more flexible.  whats wrong with having just one general move function, instead of 4 or 8 different functions.//IE:void GameCharacter::move(int dX, int dY){    x_pos += dX;    y_pos += dY}What's best for your specific implementation is up to you, you're the one who is working on it.I see how this works and I like it. I think the problem I see with 1 function is I'm not focusing on 360 degree movement, but 4 hard directions, which is why I would be more inclined to go with 4 individual functions. ;  Definately do what you feel is best, but even with only 4 directions, or even 2 directions, I personally would still use a single method instead of hardcoding one for each direction.The reason I would do it is because of the way I look at coding.  When I write a function like this, I consider what else might need to "move" in my program, and I try to structure things (within reason) so that other objects can share that new method.Inside the move method, if I hardcode the player position I can't use that method for moving monsters or powerups, or whatever else I may want to move.method MovePlayerLeft   player.position.x = player.position.x -1endHowever, if I make the function as generic as possible (within reason), I stand a great chance of killing 2 or more birds with 1 stone, as the saying goes... method MoveObject(object obj; vector dir)  obj.Position = obj.Position +direndNot that I actually like to run around all day killing birds with stones or anything... honest!  =)   ;  Why would you want to use that function for AI based characters anyway? Shouldn't they have a function(s) that handles that inside of their class?   