2d game boundaries
Author
I am building a 2d game with movement similar to Double Dragon and wondering what others thought a good way to handle defining the level boundaries would be.
My first plan was to make a list of linked polygons that any entity could move in but then started to think maybe it would be better to just create blocking entities. All entities could then go anywhere by default but would limited by invisible wall entities. The reason I like the second idea more now is because I could then use one system of collision for all entities instead of having to test against a list of boundaries during movement and then collisions with other entities later. The only reason I am hesitant to just leave the first idea was I was able to group objects based on the bounding box they were in but I'm not sure that was buying me anything.
Sorry if this seems to be an amateurish question but this is the first full game I have built so I have yet to realize all the pitfalls and am worried if I let this go to far my engine may be fundamentally broken.
I find blocking entities to be the most intuitive solution.
Depending on your collision detection algorithm, the only real drawback of this method is that of having to deal with fast-moving objects potentially passing "through" these entities.
Depending on your collision detection algorithm, the only real drawback of this method is that of having to deal with fast-moving objects potentially passing "through" these entities.
I typically find the structure that provides me the best of both worlds something more like this.
class Object;
class Entity : public Object; //Entity IS An Object
class Boundry : public Object; //Boundries are NOT Entities.
The collision procedure checks Object -> Object. This gives you the benefit of having one collision system like you wanted, Object->Object collision but also to have entities as a separate 'type'. I look at entities as the characters in the game, not just anything. So a coffee pot, even if it can make coffee, be moved from one counter to another - it is an object. (Unless of course you have a game where unusual objects are characters...) An entity/character can walk up and use or move the coffee pot object.
Finally I leave with this:
I learned from trial and error. i am not saying this is the best way to learn for everyone, though trying new things out, watching it fail - and understanding why the design failed was among the largest motivations for me. Knowing why something doesn't work is as important (in my opinion) as knowing why something does. So my advice here, is keep trying things. If it doesn't work, you learn something - and you might even learn when that technique _would_ work, even if it doesn't on the current project. Of course for something more than a hobby/education project, trial and error may not be suitable.
I hope that helps, happy programming.
class Object;
class Entity : public Object; //Entity IS An Object
class Boundry : public Object; //Boundries are NOT Entities.
The collision procedure checks Object -> Object. This gives you the benefit of having one collision system like you wanted, Object->Object collision but also to have entities as a separate 'type'. I look at entities as the characters in the game, not just anything. So a coffee pot, even if it can make coffee, be moved from one counter to another - it is an object. (Unless of course you have a game where unusual objects are characters...) An entity/character can walk up and use or move the coffee pot object.
Finally I leave with this:
Quote:This is the first full game I have built so I have yet to realize all the pitfalls and am worried if I let this go to far my engine may be fundamentally broken.
I learned from trial and error. i am not saying this is the best way to learn for everyone, though trying new things out, watching it fail - and understanding why the design failed was among the largest motivations for me. Knowing why something doesn't work is as important (in my opinion) as knowing why something does. So my advice here, is keep trying things. If it doesn't work, you learn something - and you might even learn when that technique _would_ work, even if it doesn't on the current project. Of course for something more than a hobby/education project, trial and error may not be suitable.
I hope that helps, happy programming.
Hey blackbird04217,
I like this. If I could expound a bit to see if I understand you. An Entity can be considered an "Actor" where there may be animations applied like arm raising gun to eye level and walking. Where a coffee pot being an Object not an Entity implies it isn't an Actor, its just a thing that has a position in the world and can be movable or not.
Steve
Quote:
class Object;
class Entity : public Object; //Entity IS An Object
class Boundry : public Object; //Boundries are NOT Entities.
I like this. If I could expound a bit to see if I understand you. An Entity can be considered an "Actor" where there may be animations applied like arm raising gun to eye level and walking. Where a coffee pot being an Object not an Entity implies it isn't an Actor, its just a thing that has a position in the world and can be movable or not.
Steve
Exactly that, yes. Although animations may/may not apply to the Object as well. I think you are on the right track that Entities/Actors can do/act upon things, while objects might, but in a much different way. Hmm, I am finding it hard to describe the actual separation, but I distinguish it between the player, enemies, npcs - "characters" of the game would be considered Entities/Actors while the CoffeePot, Puddle, Door or Tree would be considered objects. Even if the door can play an "open/close" animation, or a puddle can affect a robots electronics, it does so differently than the robot collecting rocks. (In this situation the robot is an Entity, and the rocks and puddle are Objects in the world.)
Hope that clarifies it all, happy programming.
Hope that clarifies it all, happy programming.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
