Topics

Splitting off from this thread: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=44230.0

But now I've got a second, smaller submission: when you add a new audio file to your project and the file is within your game directory, store only the relative path and not the full absolute path.
This has been a major pain for our project because we share the project files between different members of the team (and sometimes between multiple computers of one member) via SVN and the absolute paths are different on almost every machine.

The secondary issue I guess would only be a problem if multiple people are trying to modify the sound files? Otherwise I'm not sure I understand the issue. The audio cache is automatically updated if the source file exists and is changed, so you're saying that the source file (within the project folder) may need to be modified by one of the members of your team, but if they don't have their copy of the project in the same path as the person who originally added the audio file then it's not automatically updated? This change sounds reasonable to me, though it wouldn't really be too hard to just delete the file and reimport it.

Ideally, we'd like to exclude AudioCache from the repository and only share the original files.
Not only does it feel cleaner, it also keeps the repository smaller and updates/commits faster if there are large audio files.

The fact that the paths are absolute forces us to choose between the following options:

1. Keep both AudioCache and the original audio files in version control.
Every change needs to be uploaded/downloaded twice because of the data duplication.
If an audio file is updated by someone whose absolute path is at the moment different from the original upload's, the update won't make it to the cache until someone with the original path runs AGS, saves the project and commits the AudioCache changes.

2. Keep only AudioCache files in version control.
This takes care of the duplication, but difficult to maintain (and not really designed to be maintained by the user in the first place).

3. Keep only the original files and convert the absolute paths to relative ones by editing Game.agf externally.
This is the solution that currently works for us, but is rather annoying to maintain and we often forget to do the cleanup. It could easily be automated by the editor with a simple change.

Hey, I was hoping we could get some clarity on how the development of the official version of AGS is going now that it's been open sourced for a few months.

The big question: Who decides what goes in and what doesn't?

From the SVN history, I can see that apart from CJ, a few community members (e.g. tzachs, monkey_05_06) have commit access and are working on 3.2.2.

While the community's wishlist is endless, what interests me are cases where a member actually implements a feature they want and shares the source code. Obviously, you can't blindly accept every contribution without verifying its quality. And even a high quality contribution may require maintenance in the future if it's complex.

I'm assuming that CJ is too busy for this and the main reason for open sourcing the project was to delegate such tasks to someone else.

So if I want to submit a code change for potential inclusion in the official version, who should I contact?

So far I've tried this once, through a thread on the forum: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=43416.0
But that didn't really go anywhere. Which is actually a bit of a good thing since I later decided I want to tweak it a bit; I'll add details to that thread.

But now I've got a second, smaller submission: when you add a new audio file to your project and the file is within your game directory, store only the relative path and not the full absolute path.
This has been a major pain for our project because we share the project files between different members of the team (and sometimes between multiple computers of one member) via SVN and the absolute paths are different on almost every machine.
There's a simple fix for this, but we'd need to use a custom-built AGS to benefit from it and I'd much rather prefer having this feature in an official build.

So do I send the code to someone, or is AGS heading into a future of dozens of obscure and incompatible forks?

Hey, CJ, could you give a rough estimate of how much work it is to open source the AGS.Native library?

Just the order of magnitude - are we talking about days, weeks, months? Years?

And when it's released, please someone post in this topic so I'll get a notification

Thanks.

I've found the current AGS file structure to be fairly inconvenient for concurrent editing (for example, sharing the project via SVN), mainly for the following reasons:

• Game.agf contains timestamps of audio files which seem to get updated a lot. Sharing this between different people leads to lots of needless editing conflicts.
  
  
  
  • This is amplified by the fact that the AGF file contains too many things. A tiny edit almost anywhere will modify the file and bring out the timestamp issue.
• It seems CRM files contain a compiled version of the ASC source. If one user modifies the background image and another user only modifies the script, both will get a modified CRM file that's impossible to merge because of its binary format. There's a workaround for this - if you only modify the script, you don't really need to check in the modified CRM - but it's still quite inconvenient.
• The sprite file can easily grow huge and it's unmergeable.

So I'd propose the following solutions:

• Break Game.agf down into smaller files. For example, one XML for AudioClips, one for Sprites, one for Views, etc (possibly into an XML subfolder). The timestamp issue would still be there, but it'd be limited to a much smaller scope.
  
  
  
  • I've also considered moving the timestamps into a separate "local settings" file that would be auto-generated if missing and never checked into source control.
• Break down CRM files, to separate the compiled code from the more static content. Possibly move all Room*.* files into a Rooms subfolder.
• Break the sprite file down, possibly something like one actual file per one "virtual" folder you see when viewing sprites in the editor.

I've started working on this for our project and currently I've got a proof of concept for the AGF split done.

But I realised there might be more interest in this in the community and we might eventually want something like this in the official AGS as well (provided it's backwards compatible). Is this the case?

[90-95%]

Oh. Hello.

I'm gonna start off by breaking the "ONE thread per game only!" rule here. Technically there is an older thread for it, but it's from over 4 years ago. So I'm gonna go by the "DO NOT dig up old threads!!" rule instead. Also, pcj (who started the previous thread) is pretty busy these days and might not always be around to edit the old post.

Right then, let's get to the point. We find ourselves in a fairly odd situation. The progress report should illustrate it rather well:

- graphics 90-95%
- dialogue/puzzles 95%
- programming/assembly 5%
- music/sound 90%
- voices 5%

As you can see, we've pretty much got through most of the traditional hard parts (in other words, the graphics), but then got stuck trying to put it all together. Our main AGS engineer, pcj, no longer has time to actively work on the project. And the rest of us don't have a lot of time or AGS experience either.

Anyone interested?

If yes, reply here and tell us how much AGS experience and/or free time you have. A good combination of both would be most excellent.

If not, here's some more required elements of this post that may or may not change your mind:

Plot outline

Some time after SQ6 (possibly after SQ7 as well if it ever comes out), Vohaul is resurrected as a robot. And he strikes back. At Roger. Who then strikes back at Vohaul for striking back. Basically, a lot of backs get striked and in the end, (SPOILER ALERT!) the good guys win.

Screenshots





Flash simulation of what one in-game scene might resemble once properly put together in AGS

Click here