Messages

Oh, also I really encourage the use of decentralised version control like git and mercurial. It means people can work separately without bother and decreases the amount of administration needed and that we can use. I prefer mercurial because it's lightweight and easy easier to learn.

In that case, we might want to try Atlassian instead.
It's also free for open souce projects.
And although my experience with both Git and Hg is rather limited, I also prefer Hg.

We'd definitely want his blessing, but it might be a good idea to first figure out what exactly we want to do and how we would do it.

In that case - anybody volunteering to be the chief?

As for setting up all those things, this page looks useful: Comparison of open source software hosting facilities

Out of those, I'm most familiar with Google Code, but only as a consumer and not as a project owner. If anyone has better suggestions or bad experiences with GC, let us know. Otherwise, I propose that the eventual chief starts a new project there.

As for the repository, it might be a good idea to clone the current one to the new environment where it would be linked to any additional tools. So the community would maintain their own repo, users, etc while merging in any changes that are made in the official repo.
And at certain points, the leader(s) could propose certain sets of changes to CJ and offer to merge them into the official repo. This way we wouldn't need to bother CJ with setting up SVN accounts for everyone, etc.
Or maybe I'm overthinking this.

Allright, looks like we've got quite a lot of agreement on two things:

1. Creating a new subforum.
Is this something that only CJ can do?

2. Establishing some sort of a developer panel.
I guess to get started with this, we can either tell CJ about the idea and expect him to figure out who will be in it.
Or, to make things simpler, we can do some nominating and discussing to recommend a list of people.
I'm pretty much a noob in the AGS community and don't really know people, so it's up to you.
Reply to this thread and nominate yourself and/or other people who you think should belong in the panel.

So it seems at the moment, the process for submitting code to AGS is more or less:

1. Start a forum thread in the middle of various other technical questions and discussions.
2. Hope that CJ notices it and has time to get involved, discuss the feature, point out any required changes and all in all, decide what to do with it.

I see some room for improvement.

So here's a proposal:

1. An official group of active trusted community veterans is formed. Probably including the people with SVN commit permissions, etc.
2. This group will be tasked with actively monitoring the forum for code submissions. Could create a separate subforum for that to make it easier.
3. The members will carry out the initial evaluation of the submissions, filtering out pointless ones, recommending changes and otherwise ensuring proper quality.
4. The members notify CJ of the more viable submissions, requiring only a yes/no response (unless CJ wants to get more involved).

Or something similar. Whatever establishes more clearly who should be doing what in order to keep things moving. And mitigates the bottleneck of CJ's amount of free time to spend on AGS.

It seems to me like there's a lot of potential in the AGS community, but a lot of it is going to waste because of a lack of organization.

For the code changes I've proposed, I'd be happy to get any kind of a clear response, even if it's a "no". I'd just put our team on a custom build with features that only we need and stop bothering you all about it.
But right now it's in a vague "nobody really knows what's going on" area that's rather discouraging.

As for the idea of splitting up some of the project files, I'm not sure that I see the point of it. It seems a very rare and odd occurrence that anything should actually go so wrong as to corrupt the AGF file. I'd reread your other thread, but I'm not going to be online too much longer. I'll take a look later on.

We haven't had any problems with file corruption, but the sheer size of the file (currently over 5MB for our project) leads to various issues.

For example, comparing two versions of the file gets pretty slow. I personally do this quite often. When other team members make generic changes in the editor and commit the results, I can check the diff of this file to see what exactly happened. Or before I check in my own changes, I want to see what actually changed in the files and spot any temporary hacks I made that weren't supposed to go in (like changing the starting room of the player character, etc).

On a slow connection, this can take a while, though, because even for a single line of change, I need to download two versions of the entire file (>10MB), containing things like indexes of all the sprites and views which I'm not interested in at the time.

Also, if for example, one person changes some sprites and audio files and another one changes character properties and some dialogue, it'd be nice to see from the file level that there are changes in Sprites.xml, Audio.xml, Characters.xml and Dialogue.xml rather than 4 edits to a massive, generic Game.agf where I'd have to review 4 large diffs to get that information. And there could be a good chance I'm not even interested in the sprite and audio changes and could just skip reviewing those files. Sure, commit comments can help, but you can't always rely on them.

There's probably not a lot of AGS projects that use version control and within those teams, many members may not bother to check these diffs. But for those that do, this would be an appreciated change. And making AGS more version control friendly could encourage larger teams to use it for larger projects.

Besides, you've already got the code that does this   ...well, except for these last changes I want to make. But if there's any chance this will go in the official version, I'll get right on them.

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.

(I'll open a separate thread about the music path issue - I wanted to keep the focus of this one on the overall process)

So the preferred method for proposing such changes is still to open a forum thread?

PS. Apart from the issues I've mentioned, there are more improvements coming up in the future if I find the time to implement them.

Note: if anyone's interested in integrating this to the official version, contact me first.
I'd like to modify this so that the backwards compatibility logic would be separated from the main logic as much as possible. Otherwise it's a slippery slope towards an unmaintainable mess of intertwined legacy code.
But I'm not going to put much effort into refactoring this if I'm just talking to myself here

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?

Is there any word on when this will become the official release, or when the bugs identified thus far will be fixed? I ask because I'm just on the verge of adding sound/background music to my own game, and if 3.2.1 offers big improvements in this area, I'd prefer to use it instead of 3.1.2.

Or is 3.2.1 such an improvement that I should just switch right away, without waiting for the release to be officially on the website or the bugs to be fixed?

Looks official to me already

The timestamp thing is definitely a problem that should be looked into, although I'm not currently volunteering to do that.

However, I consider it to be a separate issue that Game.agf contains data for almost every aspect of the game. It makes project sharing less convenient even without the timestamp problem that amplifies it.

So I'd just like to hear the devs' opinion of it - if it's not going in the official version, we'll start using a custom build for our project; otherwise, we'll stay on the standard version and wait for the update.

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.

Phase 1 complete - Game.agf has been split.

You can find my changes here: http://dl.dropbox.com/u/3110371/ags/AGS_Game_agf_breakdown.zip - unzip these files over revision 48 from the SVN.

It's backwards compatible and creates new files in the XML subfolder, leaving Game.agf fairly small (in our project's case, under 6 KB).

If anyone with commit rights to the main SVN finds it useful, feel free to add this to the official codebase.

Could use a review by more experienced devs, though. I also left a TODO note in AGS.Editor.AGSEditor.LoadGameFile about a version check that should be added; it's up to you which exact values to use, based on the release plans.

Gonna look into splitting CRMs next, but my gut feeling tells me it'll have to wait until AGS.Native is open sourced.

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?

I should probably note that SpacePaw is already on the team.

However, we don't mind having more than one guy doing all the put-together-....ing, as long as we/you figure out a proper way to collaborate on that without everything turning into an out-of-sync mess.

Anybody got an SVN repository lying around by any chance?

Also, please leave at least your e-mail and/or MSN address when applying.

Can you show some more of the character stuff, as in the first image it really looks ugly compared to the beautifull background and image 2..

Sure can. Check out the new link at the end of the first post.

Or just click here

As for the character style, we have a large amount of animation in the game and trying to have the same style as the backgrounds on every single frame would've been madness (and a perfect way to kill the project).

Instead, at this point we have the entire game animated by just one guy (Datadog), which I think is pretty impressive.

Isn't that bg from the end of SQ4?

It's the same room, but redrawn in VSB style.

[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