Hello Felgo,
I am playing a lot with levelEditor currently and found few cases which I come across very quickly, which could be a litter better handled in LevelEditor(imho).
Apologize if I missed something in the docs but couldn’t find obvious solutions so I come with my own one, which I use currently.
Potential improvements:
1.
Problem: Loading authorGenerated levels involves knowledge of implementation details of the LevelEditor.
Current solution:
levelEditor.loadAllLevelsFromStorageLocation(levelEditor.authorGeneratedLevelsLocation)
Using that general purpose method is nice but, since you have shortcuts for loading community levels etc, some shorter could be useful, for example:
// Inside LevelEditor
function loadAuthorGeneratedLevels() {
loadAllLevelsFromStorageLocation(authorGeneratedLevelsLocation)
}
// to call outside:
levelEditor.loadAuthorGeneratedLevels()
Not only it is shorter but it also hides implementation detail, just a little higher level abstraction that using generic loadAllLevelsFromStorageLocation method.
2.
Problem: Detecting if we are operating on new level or not.
This is the only easy way I found to do it, if there are other sorry, missed them.
Current solution: Comparing if level(levelEditor.currentLevelNameString) name is “UndefinedLevel”
It works ok but there are few issues with this approach.
It is highly tied to implementation, it is not easily available and it allows potential issues if somebody would like to save level this reserved name.
I see two ways to handle this.
First approach, just create a readonly property which holds reserved name for new levels.
For example:
//inside LevelEditor
readonly property string newLevelName: 'UndefinedLevel'
This way changes to this string value wouldn’t affect changes in the code, we would check the property not literal value.
Second approach, extension of first one:
We can keep the readonly property but also add a method which informs if the level is new, for example:
// inside LevelEditor
readonly property string newLevelName: 'UndefinedLevel'
function isNewLevel() {
return newLevelName === currentLevelNameString
}
In general these changes help to hide internal logic which shouldn’t be really used by clients of the object.
I like the idea that there are low level methods which give more flexibility, but sometimes adding few more higher level ways to do stuff, can be helpful.
I hope this has sense what I proposed, I am not saying current interface is bad, opposite is quite good, don’t get me wrong 🙂
