The XML file just has a string attribute called hasCol, and that just makes the game object creator create a box collider. We should make this system more flexible to include other types of colliders. What if objects are differently sized. Maybe we should have a colliderdata class that creates colliders for us.

We should make the graphics system more complicated.

For Furniture, the setup is as follows

• The the XML, there is a graphics node
• This contains only 1 ImagePath
• This one ImagePath is used as the sprite

We should set this up for corner pieces and more complicated sprites. What if we have more than one sprite that we choose randomly from? Consider making a modular graphics class that can create GameObjects from data (maybe this is excessive abstraction?)

For the sake of getting something working, I'm having the world importer only import furniture, for now. I can't see any easy way around this except to have multiple image layers (i.e., a furniture image, a tiletype image, enemies image). For now, I'm just importing the furniture and tiletypes and other things are completely ignored. We may want to scrap this method of storing levels altogether, as players will be able to easily modify them (unless we replace StreamingAssets with resources, which has other problems).

A lot of the code (particularly in the World area) is intended for a finite world. How will this work as we scale up to an infinite world? Maybe the WorldWidth will be the Current generated world width. I don't know. Though I feel like having the current generated world width would be extremely CPU inefficient (though we may not need to worry about that).

There are much better ways to achieve a Camera follow that don't involve awkward screw-ups with Unity Physics or rotation and stuff. What if we use root motion for animations? Or any type of non-sprite based animation? That would cause problems with just childing the camera to the player.

Unity's Input Class is great at keyboard input, but is greatly lacking at mouse input or other enhancements. It would not be too difficult to have a PlayerController, which accepts input, and a separate PlayerMotor that attempts to get Unity's physics to work. This would allow for easy modification of movement, then a Move function could be called on the PlayerMotor.

A lot of things could be organized better throughout the project. For example, the WorldGameObjectCreator is creating Furniture (though I will likely improve this soon). Although it's not a priority if it works the other way, code should be organized so we don't have to hunt though 20,000 lines of code to find that one function that does that one thing.

Blame Rito. Go to the top and move down. It breaks.