Hi,
I'm using AGS at school to introduce my pupils to programming and therefore have installed AGS 3.1 on our PCs - and upgraded to 3.1.1 not long ago.
The problem is: every time when there's a new version of AGS, projects edited with that new version won't run on older AGS versions, e.g. if some of my pupils upgraded to V3.1.2 at home their projects won't work at school unless I update all PCs.
Is there any workaround for that problem or are there plans to handle such problems in future releases of AGS?
Greetings,
Glenn
I beleive thats an importrant technical question. So far backwards compatability between versions has been an impossibility. I think we should start exploring ways to address future versions with backwards compatibility such as Glenn has expressed. It would be nice to clear the bridge between versions for small and large projects with a revised editor version.
Cheers,
Sparx.
Nope, which is why you are always warned when you open up an older project with a newer version.
However, it's only been recently that new versions have been whipping out. (CJ said at one point that he had a large break, but that it would be ending). Obviously he'll have the final word, but I don't think there will be many new releases soon. Just as long as none of your kids install the beta versions...
[Edit]: Actually backwards compatibility is a huge issue for CJ. He works very hard to make sure that installing and updating to new versions won't break functionality from previous. And when he does, it's with good reason (interaction editor, for example)
~Trent
PS-Dang, I wish my school had a programming class. The teacher that taught the only one retired the year before I got into highschool.
Allowing the editor of an older version to open game files saved with a newer version is a big no, as in that case you don't know if things will be messed up by the old editor. Since in general, new versions have bug fixes as well as new features, it would be awkward to have an editor to load files saved with a new one, which may introduce unexpected things like bugs of old version popping back up (which should have been eliminated once the game files were edited with a new version of editor) and if new features were used when you save the files with a new version, we cannot predict what would happen when you open them with an old version.
One good [anti-]example is Flash. I know when you embed a swf properly in a webpage there may be proper checks so that the browser's plugin will be updated if necessary, but if you have a bare swf file and you drop it in a Flash Player or a browser where the Flash plugin is not up to the version the swf file requires you can still load the swf file without any warning but any sort of unexpected behaviour may happen (such as buttons not working or screen FLASHes, etc.). This is definitely not cool.
The only safe way is to manage what version of AGS you actually need in your game and try your best to use the same version in any of the environments you will edit the game. For example, in your case, if your school only have V3.1.1 and there's no way (atm) you can upgrade it to V3.1.2 (atm), remind your pupils to use V3.1.1 at home. They can actually install two versions of AGS in the same computer. One good advice is, backup the game files frequently, so that if a person, say, accendentally opens the files with V3.1.2, you can still restore the backed up files to a point before the update. Unfortunately, due to the rise in the usage of Vista and the move of AGS to an installer version it may not be always possible to install software on any system without enough rights and tweakings (like for example the school network, thay not any one can install or upgrade software themselves). Luckily, RAR non-installer versions of AGS are still provided, which may help if it is impossible for you to run the installers.
Just a thought, perhaps you could install 3.1.2 on a few computers rather than 20-30. Then, any of your students that want to go the extra mile and have the newest version at home (or even those that need one of the bug fixes) can use those computers.
Unless you have your classroom set up differently, such as each student uses a specific computer.
~Trent
It rare that old versions of any software support newer versions' files, except where the file format is a standard across many different programs already anyway (.e.g. JPEG, MIDI, etc.) The one exception I can think of is MS Office 2003 which you can get a plugin for to let it open Office 2007 files.
Why not have a network drive which has different versions of AGS on it, that way students can start the one they need. AGS doesn't REALLY need to be "installed" on a PC, all that that really does is set up which editor gets loaded by default when you double click AGF files.
I'd say keep the school computers updated with the latest stable version of the editor. Since you're already up to AGS 3.1, Linux compatibility and the interaction editor are no longer issues anyway, so there's no real reason to work on anything but the latest version. I've yet to see a game being broken by updating it to a stable version, but of course you should tell your students to keep backups whenever they update their games.
Yes, the problem with allowing this is that you would lose data.
For example, 3.1.2 introduces the new CursorImage property for inventory items. Suppose you loaded your game into 3.1.2, and set the CursorImage on some of your inventory items.
If you then loaded that game back into 3.1.1, it wouldn't know what the CursorImage property was for, so it would throw away that information. Then when you loaded the game back into 3.1.2 later, you'd find that all your CursorImages had disappeared.
I think all you can do really is warn your students about using the right version. I know what a pain deploying new software around an organisation can be and why you're not able to just deploy 3.1.2 to all your PC's, but until you can upgrade they just need to know to use the same version at home as you're using in the lessons.
QuoteI'm using AGS at school to introduce my pupils to programming and therefore have installed AGS 3.1 on our PCs
My first thought after reading this was 'But if you want to introduce them to programming, why aren't you showing them an actual programming language with compiled examples?' AGS has c-style scripting but it's far from being a robust programming language like c++ or c#. Even if you're teaching game programming, aside from maybe an example AGS game that you can show code excerpts from, you still won't want to rely on a
game making tool for your course work, which it seems like you're doing based on your concern with keeping AGS current.
I went to an overpriced game design school, and we used Dark Basic in our "programming" class.. i think it was probably just to accustom us to what code looks like, and try to help us understand a fraction of what a programmer may come by our desks and say..
..In my case, it didn't really help. But I'd been programming in simple languages since 7th grade, and still have now idea what those dudes are complaining to me about :)
Quote
My first thought after reading this was 'But if you want to introduce them to programming, why aren't you showing them an actual programming language with compiled examples?' ...
IMHO, with AGS it is quick and easy to make progress and accomplish something. Students are able to get a "quick fix" that will encourage them to continue. In an "actual programming language" it is nrecessary to learn a whole bunch of boring "junk" before getting any kind of gratification (except of course for the hardcy and truly geeky individuals...). So I think AGS is a good choice for an intorduction to programming.
Quote
I beleive thats an importrant technical question. So far backwards compatability between versions has been an impossibility. I think we should start exploring ways to address future versions with backwards compatibility such as Glenn has expressed. It would be nice to clear the bridge between versions for small and large projects with a revised editor version.
One could begin to address this issue by simply displaying the AGS editor version the game file is compatible with instead of just saying that it was created with some earlier version of the editor. At least then you would know which version of editor is needed.
The next step would be to devise a standard method of installing multiple versions of the AGS editor on the same machine. If an older version game file was opened with some future version of the AGS editor a dialog could popup stating which version of editor the game file is compatible with and give the user the option of upgrading or of launching the appropriate version of editor. Just some thoughts...