@wlomas This question has been answered before. The problem with extending the test out till final release is exactly that, people would probably be reporting bugs for a dead version left and right. Or reporting that their old maps aren't working with the latest new build. The only hypothetical way this would actually be able to work off technicality alone is if they had an always-on disclaimer when the engine started instructing the users outside the testing team not to send feedback for this build, or their email will be ignored in the order it is received. And how much do you wanna bet people are actually going to honor that. We all know every time an honor system is deployed in the community there's always one that is going to make it crash and burn, unfortunately. Plus, it would not benefit you being able to polish your projects until the final product anyway, because you are absolutely right it likely will be in another language altogether, and you can't just move it over/finalize it in the final build. THat being said, perhaps a sort of read-only mode may be a good idea to curb that, so that if people make something memorable during this test period, they can go back and replay it as a point of reference of sorts when they go to construct their game in the final build, i.e. generally more or less what their map looked like, the text lines so they don't have to be typed in again, etc. long and short of it, using their progress made in the alpha build as a breadboard of sorts for their final product. That kind of implementation would only be possible if the drm system they are using has breakpoint/trip-wire functionality where they can simply move the check_date/check_license function over to trigger when someone goes to create a new game/goes into creation/debug mode. But if what they're doing is simple try-and-die drm, this implementation would run the risk of having something public alpha-specific coded in, when there is so much more to the engine that must needs doing before final release.