CurryKitten
commented
2 years ago Been working on this for a few days. The base stuff for the original level to load the terrain/assets afterwards is ok and I've constructed a class to hold the level metadata and then a manager to process this and then call upon the other code to update references to objects that they'd lost due to the level load.
The larger job actually comes with the scenario menu - where we have a lot more objects flying around to take care of, so I ended up with a separate scenario metadata class as well which has to describe the chase maps/speeds/different models etc. Actually, the metadata is the small task, getting the scenarios menu code to process all of this is the bigger one
The way this project has evolved means it wasn't really built with a proper structure from the get-go. Rather, additional features and modes were tacked on, and whilst the necessary integration was done in order to make things work - it wasn't done with any future expandability in mind.
This became most obvious when putting in a new level - such as the recently added City. Instead of being able to drop a new level in place and have all the existing code work, because of some differences in some of the things that could/couldn't be done I ended up with a lot of code duplication, and specific city-only and desert-only scripts. This is obviously a bit of a mess and I need to be able to easily drop in another level should I want to. Given that people want variety, it can always be the case of level base first and then stuff like chasing/racing/etc later.
If we take a look at the objects in play in each of the levels. The original "desert"
and the city..
We are only persisting the Rewired Input Manager between the levels, the rest of the objects are being garbarge collected and then added back in with their own individual instances and properties. This is massively inefficient and a pain to add new levels.
Whilst each of the features of the levels should be individual - i.e the terrain, and buildings etc, all the UI, the quad/plane/car should be kept between levels and only GC'd when we are going over to Online or the game. What we need to have in here is a class to represent properties of each level so that part of the level load will update the necessary objects with the new correct information. Such things would be the reset position of the quad/plane/car, whether the UI should contain an option for weather, or time of day, graphics to update the chase UI maps and waypoints etc etc.
This is quite a large job, but a good test of it would be to release with several new levels to see how easy these can be dropped in place.