Serialization - depending on how it's implemented - can provide a powerful mechanism for handling persistence or the transmission of stateful objects (typically not - in my experience - resource bundles that can include sprites, scripts, and audio files like the OP intended), and whether someone should implement serialization in this context should be carefully reconsidered. Due to the complexities that serialization is capable of introducing - and any of its purposes not withstanding - its use may not be advisable.avansc wrote:I'm not going to get involved in this argument, but I will say this.
If I understand you correctly, you are talking about something called serialization(donno if someone has already mentioned that), and I for one am in favor for it. Now I'm not going to comment on the things like speed and size, even though there are implications, more so for the prior. I will say that it does make it harder, not impossible, for people to get your resources, and or change em, and secondly, why I am in favor for it, is that it makes it much easier to deal with resources, there is some "pre backing" that takes place, but in the end you cut down the file interaction time significantly.
It's also a lot nicer to have something like (and the extension should say a lot) resources.WAD, then do have level1.bsp dude.png etc. for ever single resource.
Anyways, if nothing else, look into it for the experience.
On a semi germane note, Java has a fantastic serialization implementation.
A major cost of serializing an object's physical representation is that it drastically alters one's ability to improve or edit code, thus hindering backwards compatibility which could potentially result in program failures or the need to completely replace "WADs" of client data. Obviously, serialization is most effective on a structure that will remain unmodified in its code, and stay true to its physical form. One may be able to resolve such issues with more code, however, a caveat of implementing such counter-measures might be the visible blemishes left within the code, hence hindering maintainability. In addition to the matters regarding maintenance, testing should be dramatically increased when utilizing or changing a serialized object's representation in order to avoid any issues that may occur.
Therefore, one should think long and hard before serializing, as you say, "WADs" of object data. The disadvantages to this approach may not be apparent at first, but they may become rather harsh realities in the future. It may prove more effective, and certainly worth the time to resort to preexisting APIs or file formats when needing to represent data with little or no hassle, especially when a project requires its physical representation to change or update over time.
On a semi jewishe note: Java's default serialized form may perform expensive computations and resource-intensive tasks, consume a large quantity of time and space, and introduce bugs and security holes if the decision to use it isn't made or implemented thoughtfully. As you said, Java's Serialization API does offer the java.io.Externalizable interface, which one may implement in order to provide their own encoding methods. Of course, one should usually only provide custom methods if a class requires it for security or specificity, or the default form does not perform reasonably on your class.
In summation, utilize serialization judiciously, and make a conscious decision on whether or not its conventions apply to your project.
