This project is read-only.


Revamp WorldBuilder, Level, and PathFinder


Note that WorldBuilder is now simply called World as it doesn't...well, build anything anymore.
The current idea is as follows:
I'll completely hide the World object from us and everything will be taken care of by the Level constructor and object. The Level will simply contain its own World object which will contain its own PathFinder object. The result is a set of three classes which can all talk to each other if they need to. This way we can hide underlying implementation of World and PathFinder by wrapping them both up by Level.
This is especially nice because, realistically, we only need to be able to use and pass around a Level object. The World and PathFinder classes are supporting classes for Level, which means that it can build and handle them on its own. If we ever DO need something, we can just ask the Level for it. This should make code a little cleaner and move some of the code that seems out-of-place to somewhere where it at least seems a little bit more at home.


ZephidsEmbrace wrote Feb 21, 2010 at 12:52 AM

I'm currently using this issue as a whiteboard for my plans. Here they are in no particular order):
  1. The Tile class will soon have two differently functioning constructors - one for forcing a z-value and one for not. If there is no z-value given when the Tile is defined, then the Level class will determine its z-value based on position when it goes to draw it.
  2. The Tile class will have different constructors in the near future. I will add the ability to pass in a list of foregroundTiles and backgroundTiles. Then when the Level is building the SpriteBatch for the world, it will go through these and add them in front of and behind the texture (respectively) which that Tile actually represents. This way we can easily put a tree on grass and even create unique tiles by simply layering different things under/over tiles that already exist.
  3. To the end defined in #2, I may add a third constructor to the Tile class so that you can safely create new tiles with different fore/background tiles from existing ones. For example: Tile(Tile oldTile, List<Tile> foregroundTiles, List<Tile> backgroundTiles)
  4. World will act as the "interface" for PathFinder. Since PathFinder is all the raw graph data, I figure I can use World as a place for compound functions. Things that allow you to add a wall to the map so you'll determine a different path when you re-pathfind, but then that wall would go away.
  5. I'm currently looking at adding AddPlayer(Player p) to the Level class. The map contains built in stuff for the placement of a player. The Level would take the player and use its teamNumber to place it at the number defined on the map (for now, at least, we can assume the player will be team number 1).
  6. Need to make sure to update the AddBaseEntityToTile() functions so they get added to the map properly.

ZephidsEmbrace wrote Mar 7, 2010 at 12:39 AM

Regarding the notes in the last comment:

1, #2, and #3 are all complete.

4 Not yet complete since we haven't gotten Pathfinding actually doing anything right now.

5 This hasn't yet been implemented, but also requires the revamp of Player to be completed first so I'm waiting on that.

6 Done but I still need to remove the legacy functions as well and I can't do that until all of Brenden's code is checked in but this is probably the first priority on the next changes to these classes.

ZephidsEmbrace wrote Mar 14, 2010 at 9:33 PM

Closing and making a new issue for pathfinding.

wrote Mar 14, 2010 at 9:34 PM

wrote Feb 1, 2013 at 1:01 AM

wrote May 14, 2013 at 1:18 AM

wrote May 14, 2013 at 1:18 AM

wrote Jun 11, 2013 at 1:24 AM