Messages

[Please backup your game before using this version!!!!!!!!]

Please backup your game before using this version!!!!!!!!

Download here!

Edit: replaced with a new version that also fixes the bug described here

Edit 2: replaced with a newer version that fixes a bug and implements a few suggestions, both described here

Edit 3: replaced with a newer version that fixes a crash when clicking "go to definition", described here

Edit 4 (18/7/12): More fixes described here!

Edit 5 (20/7/12): More fixes described here!

Edit 6 (21/7/12): More fixes & improvements described here!

Edit 7 (22/7/12): Fixed the crash described here!

Edit 8 (29/7/12): Committed the changes to the 3.2.2 branch.

Hi, I've added a few features for the editor.
Please test and/or provide feedback.
Once I see everything is well I'll commit to 3.2.2 development branch.

The features:

Folders:
Added folders for characrers, dialogs, inventory items, guis, rooms, scripts and views.
Added new menu items for all folders to move up/down,
and the ability to drag/drop files to be before other files.

For scripts:
- Script and header files are now combined into one and can be expanded/collapsed, similar to room settings & script.
- I removed the ability to move files up/down, this can now be done with normal drag/drop (and not only for scripts).
- Also removed the "exclude script" option, it made things a mess and I couldn't understand why it is needed.
If anybody knows, please tell me.
- The order of the scripts (for script dependencies) is the same as it was before, a script can use all the scripts
above it.

For rooms:
- The "Sort room by number" now sorts within folders. I actually don't understand why this feature is needed, if anyone
knows please tell me.

Find all usages:
Added a menu item to find all usages for characters, dialogs, views, inventory items and global variables.
It won't actually find scripts that use the character id (or dialog/view id), just scripts that use the actual
script name of that specific object.


An example of the folders and the "Find all usages" menu item

Navigate (in tree):
Added a menu item for almost all document tabs, to navigate to their node on the project tree
(can be useful for large projects).


An example of the "Navigate" feature.

Goto Line:
In script editor, pressing Ctrl+G will now open the "Goto line" dialog, you can select a line number and the
editor will jump to that line. Since "Ctrl+G" was already used as a shortcut to open the global script,
I replaced that shortcut with Ctrl+Shift+G (and also replaced the shortcut to open the global header
from Ctrl+H to Ctrl+Shift+H for consistency).


An example of the "Goto Line" feature

Mono:
I've refactored some code to make it more Mono-compatible, so that it could run properly when compiled with Mono
(cross platform implementation of .Net).
There's still a lot more work to be done (even without mentioning the native dll), but it's at least a step
in the right direction.

The changes I've done-

• I replaced in tons of places the hard-coded "\" used as a directory separator with the directory separator of the OS,
  so that it'll also work on Linux machines.
• I switched the code that detects Shift & Ctrl keyboard presses with a managed solution, that should be supported
  by MONO- this is used when selecting colors in the palette, for example.
• I switched the code that detects when the Room Designer is focused (used when pressing the up/down arrows to pan
  the working area) to a managed solution, that should be supported by MONO.
• I switched the code that copies arrays in memory to a managed solution (used when loading a sprite from file).
• I partially disabled some features only when running with Mono, since I couldn't see a way to code them without the
  Win API:
     - Breaking in debug will not automatically set the editor to the foreground, the user might have to click on the window
     - Notifying the user on file changes externally if the editor is in focus will not happen. It will happen when
       the window is activated, so I hope it won't be too annoying.
  

And when I try to click on an issue, I get:

You are not allowed to view issues of this project.

Shouldn't it be open for all?

[technically]

Do you see what the differences actually are?
a) neither development is stopped for testing/merging time, there's a checkpoint made that mark the version of the sub-system that was given to other branches (including main) and that may be referred to.
b) branches are like different projects that evolve all the time without hacking others.
c) every branch eventually have all the code from other branches, so testing of the whole complex is eventually done by everyone involved.

a) In the first schema development also will not be stopped, since the work is not actually on main but on a dev branch. Each time a dev branch is ready for testing, a new dev branch of the next version will be created for everybody to keep working on.
b) Yes, I agree, that's the major advantage to the second schema suggestion.
c) Exactly, that's the major advantage to the first schema suggestion. There the testing of the whole complex is done sooner than eventually, which means more testing which is a good thing.

Anyways, it's clear we won't convince each other, it seems that both of us are pushing to the direction that we're used to work with.

You see, if there's one branch, and, for example, editor-focused dev finds a bug in the engine, there's chance there will be no one around skilled enough to fix that.

I did not understand your point in that sentence.

Now, with all due respect, but that's something that both ridicule me and piss me of in the situation in general.
I mean, come on, people, you have everything here. You have people who want to work. You have plan. You even have some code already prepared that could be released. Yet you keep waiting for CJ, or some "other people" who will "merge their changes" or some unnamed "community" to "approve" something.
One of the reasons I posted all this was to show you that you can actually make next release and start further development right away.

Without getting into the religion debate, technically we can't officially release a new version without one of the website admins putting it on the website download page, as far as I know the only website admin is CJ, hence we must wait for CJ.

Edit: On a side note, saw the 260 cpp files, very impressive! The most massive refactoring work I have ever seen.

[before]

Allright, a month ago I sent PM to CJ directly, and that's what he answered, quote:

This is news to me, what I said earlier was based on CJ wanting to stay in control.

Anyways, I'll try to rephrase what I said to make it more clear:

Does it have something that dev3.2.2 doesn't,except fro AGS.Native.dll?

3.2.2 is the currently "unofficial" continuation of Main, Main shouldn't have anything that's not in 3.2.2, whereas CJ's original intent as I understood it was to merge 3.2.2 into Main while reviewing all commits made, with the possibility of rejecting code changes or making changes of his own.

First of all, what that "community" that makes an approval is, exactly? Who are they? I just want to know whom I am to give my code for approval.

Arrrm, TBD?
Well, there's a difference between the feature and the code, I was talking about the feature itself, not about the quality of the code.
What I meant here was what me and other developers made before committing anything to the repo. We opened a thread, showed the application with the new feature and asked for feedback. If the general feedback was positive and there were no critical issues, we took that as approval.
This process could be made more formal, possibly.

"Open source" does not mean "open repository". The fact that everyone has 'read' rights does not mean they will have 'write' rights. If any random "volunteer" could just commit his stuff to the development branch at will - that would be true chaos. I don't know, maybe it isn't what you really mean?

No, obviously that wasn't what I meant, I'm not sure where did you get that from. I definitely want some form of code quality review process which hasn't been defined yet.

You could see I suggest to have branches each focused on certain area, not several branches on same area.

Aren't the two branches you and JJS have both work on the same areas?
When you're doing project-wide refactoring, you're bound to touch pretty much everything within that project...

Imagine everyone is working in the same branch. You commit everything there.
...
...
What version are you talking about?

I don't have to imagine it. That's how I work in my company for the last 3 years, and it's working very well.
First, a developer must run tests before committing which eliminates much of the problem.
When a developer does insert a breaking bug to the dev branch, then:
A. Yeah, it can annoy the other developers if they can't work further, but they can easily understand where the bug is coming from and work around that. I see it as a disadvantage of the system, but when you don't have too many developers, it's only a little disadvantage. On the other hand...
B. Since the dev branch is used by all devs, the bug will be found a lot sooner, and thus will be fixed a lot sooner, and this is a major advantage of this system.
C. In any way, it won't increase the number of bugs, and since the dev branch is not the main branch, the stability of the official version will not be harmed.

I agree that this system is not acceptable when you have legions of developers, but for a small number like us (in my company we have ~20 devs) it works very well in my opinion.

Btw, check this: http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html, specifically "The Branch-When-Needed system" paragraph.

No argument there, we're in agreement here, branches should be created for big projects. But once a branch has finished its purpose and is stable, it can be merged back and there's no need to maintain it anymore (again, true for a project with a small number of developers).

[Regarding the practical situation:]

Regarding the practical situation:

First of all, other than those 3 branches you mentioned, there is also the main SVN trunk.
There were no defined goals or release date for the dev branch. Basically CJ said that developers that want to insert features are welcomed to show their features to the community, and if there's an approval they can commit to 3.2.2.
I have no experience with open source projects, but it seems to me that unlike traditional software development, defining strict goals and deadlines is problematic since it depends on volunteers, who may want to implement different things in a different pace. So I think this approach, along with defining priorities for features & bugs to give directions to the developers (this is still missing but I assume that Wyz and the gang are working on it?) is a reasonable solution.
CJ kept all the control for the main trunk, and for the official beta releases.
He did this, since he wanted final say in what gets in to the official versions. So everything that was committed to 3.2.2 will not necessarily make it in the offical release.
From what I understand, the plan is to release a new official beta once there is enough new content and not based on a release date.
I myself have no problems with releasing 3.2.2 version now (even though I have new features in development), but it's CJ decision.

As for the multiple development branches:

Sharing the code between different branches is not always an easy task, it is error prone and can cause bugs, and sometimes it's almost impossible if two people took the code in very different directions.
So I think that a branch should be created when there's a big project to undertake (like the ports, or the refactoring), but once the branch has filled its purpose and reached a stable state it should be killed, and eventually we want to strive to a single version, to minimize the potential bugs.
It will also help us to find new bugs sooner, because the version will have more users, which will make the bugs much easier to fix (there is a known fact that the more time that goes by between the time the bug was created and the time it was found, it will be harder to fix the bug, where the factor is exponential).

I don't see a problem with your suggestion to merge the version from SVN to the other branches and make the main branch from there, it's just not what CJ defined (from what I understand, I can be totally wrong on this), and will require his consent since he's the one to eventually release the version and wanted total control on what gets in the main trunk.

My thoughts on this:
The official version is SVN Main, and so the tracker should track bugs regarding the main SVN branch, not the unofficial versions, and I'm not sure about the development branch, but I'm tending towards no to that as well.

Eventually we will want to merge those unofficial ports into the main trunk and release an official version (the sooner the better IMO), we wouldn't want to keep those branches alive, this could create chaos for the exact reasons you mentioned.

Thanks guys!

Congratulations! 
This will surely be a classic...

Played it and finished it!
It was hard but well worth the effort, you sure know how to please a man.. 

I really liked this art style, you should make more games with the tablet, oh, but wait..

I miss 2.72 and can't wait to get back to my art pens, but it was nice to try something new. 

Does that mean it was a one time fling?

I think it should be in separate help files (option #2).
Having it all in one help file is too much of a fuss and makes less sense to me.

Also, I don't think it requires a plugin, I think we need to add the feature to the editor.
When exporting a module/plugin, export a help file as well (maybe extract from the script comments).

Add a menu item to open the help file when right clicking the module/plugin.
When a user presses F1 search all the help files and not just one.
Also, you didn't mention it but I find this to be equally important, use the help file for intellisense too.

Just had a quick test of your manual, it looks great!
I support switching to it in the website.

A bit late to the party..
I totally support moving to a fully featured language. The fact that Unity games are written with C#/JS is one of their biggest sell points.
Assuming we're sticking to AGS script, I support Calin's idea of seperating class with struct and removing the pointer syntax, and obviously that passing struct/class as a parameter is a must.

Other than that, I think we also need:
* Delegates (function pointers)
* Nested structs/classes
* Events - not just from the designer, but being able to define custom events and having multiple subscribers. And also the ability to subscribe to the designer events from the code, so that you can select in which script file you want the event and avoid the massive global script.
* Inheritance/Interfaces, and also changing the AGS objects to inherit from base objects/interfaces (Character, Object, Hotspot and GUI should all be "Moveables"- this can make the Tween Module be a lot shorter and easy for maintenance, for example)
* Creating objects at run-time
* Generics (Templates)
* Removing the constraint of scripts and functions ordering.

- at first I said I'd use this in a new feature, and I was answered that I'm going way too fast.
- So I said I wouldn't use it, and would just add it to make the Editor's code more flexible, and now I'm being told that if it's not used, it's useless.

It's not like we're a formal institute. Different people have different opinions, and none of us have any authority... it's just an opinion.
If it's in any way been a de-motivator then I apologize, I was just raising a small concern, nothing major.
I'll shut up about small issues like this in the future, since keeping people motivated to contribute is much more important.

If you search for AGS in google, you get some nice sub-links for:

Games‏ - AGS Forums‏ - Download AGS‏ - Picks of the month‏

Out of of those, only the Games page is redirected to the new website, the rest of the links still show you the old website.

Thanks!
You reminded me, it's actually called the snowflake method and here's the article.

Are the changes to be used by plugin creators, or is this simply infrastructures for future development?
Are you planning on using those code changes for features yourself?

Basically, if the improvements are actually needed and used, then it's great, but if it just something for future potential development, then my main concern is having untested code in the system. If this will be something employed by others too then the code might get bloated and we will have trouble identifying the actual used and important code from the rest.

This has great potential!

A few thoughts:

1. When I design a game, I usually work with a deadline and a limited amount of resources. I would like to be able to take all the tasks in the to-do list, assign both people and time estimation for completion. Then I'd like to be able to put an estimation of how many hours a person would put in each day (I usually do this in excel), and then have an estimation on how far behind I am, so that I could make changes as needed,. For example, I could assign myself to work 2 hours on each week day and 8 hours on the weekend, and then if I have tasks that take more than 18 hours (2*5 + 8) then I know that I won't make it in a week and I need to cut down on something (or ask for help).
It would be awesome to have it in the software.

2. There's a methodology for writing stories (I don't remember its name), where you start your story with one sentence that captures the main idea of the story. Then you expand that sentence to a paragraph (a sort of 'elevator pitch') and add more details, then you expand each sentence of that paragraph to its own paragraph, and so on until you have your book. If somebody knows what I'm talking about and have a link with more explanations, this method is a great way to create well structured stories (and obviously it's great for designing adventure games as well), so it would be great to be able to apply this workflow in the program.

3. A tool to analyze the game 'balance' would also be great. By 'balance' I mean: Have the ability to set difficulty and types to puzzles (where the types could be tags with no restriction). Then you could check that the game starts up with easier puzzles and continues to harder puzzles and not the other way around (maybe show a difficulty graph). The tool will also check that there are not too many puzzles of the same type, and that if you have some puzzles with the same type, that they are far apart.

[Bring it on 2012!]

Aww, I missed it this year!  Shoot!

Big congratulations to all the winners, especially TheJBurger for all the wins!  And special congrats to Kris and Baron for your well-deserved awards!

Bring it on 2012!

I wanted to write this word for word!

As one who made a failed attempt to create an online real-time multiplayer game in the past, I agree with dkh that it's really not that simple, it was a nightmare for me too, and I've used a dedicated library for it (Player.IO).

Though, I've used Flash which is known to be slow, so maybe AGS with dedicated sockets would be more suited?

Anyways, if anybody wants to have a go at it, this tutorial helped me a lot (it's for flash & Player.IO, but most of the information there should probably be true to any real-time muliplayer engine):
http://playerio.com/documentation/tutorials/building-flash-multiplayer-games-tutorial/flashversion

Deu2000's signature is cut in the middle (chrome):