Movement Question
Author
Hi I have problem that I am not sure what is it categorized under.
Recently my engine is able to capture user's input (keyboard and mouse), so I'm trying to get a simple sprite to move to a point user has just clicked. I understand how to solve the programming part of the question easily but the issue is how to solve the problem that allows reuse.
So instead of simply hardcoding the function (of moving to a point user clicked) into the moving sprite itself. Should I seperate the function out into pathfinding? Is this considered pathfinding (though a simple straight line movement)? Or can anyone suggest a solution? I'm still quite new in games programming concept.
Thanks in advance.
Though others might not agree, I would say make it work, you'll have to do redesigns later anyway. When you'll have more parts working you'll be able to categorize them better.
I've stopped thinking about design issues too early several times, and I think it's not a good thing to do.
Note that I'm not trying to say designing things first is bad. Just that you have to have LOADS of experience before you'll be able to do it and you'll only get that experience by encountering design issues while developing.
Just my two cents...
I've stopped thinking about design issues too early several times, and I think it's not a good thing to do.
Note that I'm not trying to say designing things first is bad. Just that you have to have LOADS of experience before you'll be able to do it and you'll only get that experience by encountering design issues while developing.
Just my two cents...
I disagree. I believe that it is important to start design well before you even start coding. However, This does take practice and experience to know what the best design is for your particular situation. In this case, It depends on what you mean by "reuse" If you later intend to expand this straight line motion to include real pathfinding and obstacle avoidance, then you should encapsulate it and have a pathfinding function that returns some sort of path. How you represent that path is up to you, and that's another design question. inside the function, for now, it would just generate a straight line path, generally by interpolation.
If, however, you don't intend any such expansion, you should just find the straight line motion, without any encapsulation. there's no point in doing all that work, unles sit'll lead somewhere good. There's no need to reuse a linear interpolation function. Such a function will be trivial to write by the time you start worring about reusing your code.
If, however, you don't intend any such expansion, you should just find the straight line motion, without any encapsulation. there's no point in doing all that work, unles sit'll lead somewhere good. There's no need to reuse a linear interpolation function. Such a function will be trivial to write by the time you start worring about reusing your code.
While to a certain extend I agree with Morrandir's point, I don't see why it should ever not be encouraged to structure your program to make reuse easier. It may be that you will need to reuse this functionality in this project as well as later ones and the earlier you design like this, the better. You certainly seem to be thinking along the right lines.
I'd suggest two possible ways to extract this functionality out of your sprite.
First (C), a nice simple function a bit like:
Alternatively, if we are talking a classes-based language like C++, put the functionality in a Point class:
which would have the obvious advantage of seperating the initial computation of the movement needed from each individual movement step.
Sprites can then have a Point member rather than X and Y members.
There are probably much cleaner solutions that others will suggest though.
I'd suggest two possible ways to extract this functionality out of your sprite.
First (C), a nice simple function a bit like:
struct Point_s { float X,Y; };typedef struct Point_s Point;Point MoveTowards(Point P,Point Target,float Step);Alternatively, if we are talking a classes-based language like C++, put the functionality in a Point class:
class Point{public: Point(float x=0,float y=0) : X(x),Y(y) { } void SetTarget(Point P); void MoveTowardsTarget(float Step); float X,Y;};which would have the obvious advantage of seperating the initial computation of the movement needed from each individual movement step.
Sprites can then have a Point member rather than X and Y members.
There are probably much cleaner solutions that others will suggest though.
Author
Thanks for the replies.
I have already done hardcoding and it works fine. Basically I'm trying to build up a variety of useful classes as I made a simple game (network, render, etc). Thats why I am aiming for reuse in most of my code.
@EasilyConfused
I'm using Java so I'm going to try out the C++ example.
I have come up with an idea. Whenever player clicks a point with the mouse, a task will be added into a list. Main game loop will look through the list of tasks and update positions for all sprites/objects in it. Tasks will be removed when completed or cancelled out by player's other actions.
What I'm thinking is I can expand this list into AI component for my game.
Would this be workable or is there any point in doing it this way?
I have already done hardcoding and it works fine. Basically I'm trying to build up a variety of useful classes as I made a simple game (network, render, etc). Thats why I am aiming for reuse in most of my code.
@EasilyConfused
I'm using Java so I'm going to try out the C++ example.
I have come up with an idea. Whenever player clicks a point with the mouse, a task will be added into a list. Main game loop will look through the list of tasks and update positions for all sprites/objects in it. Tasks will be removed when completed or cancelled out by player's other actions.
What I'm thinking is I can expand this list into AI component for my game.
Would this be workable or is there any point in doing it this way?
I guess it sounds feasible.
The game I'm working on at the moment uses a system a bit like that for delaying tasks. For example when the player dies, stuff like an explosion happens immediatley but a screen fade and a level restart need to happen like a second and two seconds afterwards.
So the explosion is triggered in the Player::Die method, but also two messages are "posted" to a vector of events, each of which has a Delay member. The time delta is subtracted from the Delay of all the messages in the vector every turn and any whose Delay has become <=0 are acted upon and removed from the vector. Works quite well.
I suppose this approach could be extended to events like movement that happen over time and it would nicely decouple the concept of the task from the object performing the task.
I've taken the approach that every object has a Call virtual function called every frame and each object takes responsiblity for maintaining its own state and tasks internally. I've found this to be a more extensible solution than having a seperate list of tasks being performed, since a new object can be introduced independantly of the rest of the code. I've personally found that a task list is of more use for delaying events but I don't see any major problems with what you are suggesting.
Good luck with it, anyway.
The game I'm working on at the moment uses a system a bit like that for delaying tasks. For example when the player dies, stuff like an explosion happens immediatley but a screen fade and a level restart need to happen like a second and two seconds afterwards.
So the explosion is triggered in the Player::Die method, but also two messages are "posted" to a vector of events, each of which has a Delay member. The time delta is subtracted from the Delay of all the messages in the vector every turn and any whose Delay has become <=0 are acted upon and removed from the vector. Works quite well.
I suppose this approach could be extended to events like movement that happen over time and it would nicely decouple the concept of the task from the object performing the task.
I've taken the approach that every object has a Call virtual function called every frame and each object takes responsiblity for maintaining its own state and tasks internally. I've found this to be a more extensible solution than having a seperate list of tasks being performed, since a new object can be introduced independantly of the rest of the code. I've personally found that a task list is of more use for delaying events but I don't see any major problems with what you are suggesting.
Good luck with it, anyway.
Author
I see, I think what you said make more sense, I will stick with having an object maintaining its own state (currently they are doing updates on their own state).
Thanks for the tip :)
Thanks for the tip :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
