Messages

[EDIT from 13 feb 2013:For those who are new to this, the latest valid discussion starts here:http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912First posts in this topic are quite old, and arguments obsolete.//----------------------------------------------------------------------------------------------------------------]

EDIT from 13 feb 2013:
For those who are new to this, the latest valid discussion starts here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912

First posts in this topic are quite old, and arguments obsolete.

//----------------------------------------------------------------------------------------------------------------




First of all, I am not going to post any theoretic plans here, dream team lists (sorry, Di Perla ), etc.
What I want to post is a specific proposal, which, if accepted, could get under way same day.

I seem to make new threads here often lately but I thought I really must make one to separate discussion about immediate release policy from the "refactoring" thread.
I'll try to be as brief as it is possible without making nonsense.

What is the practical situation?

There are three sequentially related development branches (I mean that every next contains all the changes from previous ones):
1. dev 3.2.2 on SVN.
This branch contains only changes to the Editor, mainly to GUI look and behavior (by tzachs); also few fixes and whatnot (by Calin and monkey_05_06).
The branch did not have any update since January 2012, that is half of year already.
The natural questions are:
a) What was the goal of that branch (features, fixes, updates, etc, supposed to be implemented there)?
b) Was the goal achieved? To what extent?
c1) If it wasn't achieved, what is actually left to do? Why is no one working on it?
c2) If it was achieved, why it wasn't released?
I read earlier several discussions on 3.2.2 and also things people are wanting/trying to implement, but none mentioned release date;
FYI (but I guess many of you know these better than me):
http://www.adventuregamestudio.co.uk/forums/index.php?topic=42066.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43383.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43955.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43965.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44230.0
Basically I see the common problem: everyone is like "when the 3.2.2 is released, then..." (something good happens); but no clue who is responsible for releasing it.

2. JJS's branch
As you may know pretty much well, JJS and tobihan port AGS engine to other platforms.
JJS is making what he calls "daily releases" for all platforms, except Linux version, I believe, which is supposed to be built by users from current source.
Is there any "grand" release planned to mark a checkpoint in this work is unknown to me. How long this work is supposed to take more is also unknown to me.

3. Refactoring branch
Currently made by me, but I really hope monkey_05_06 and perhaps someone else will join eventually.
My primary task was to clean the engine code up and split it to readable units. This is almost done. In fact, I am very close to a point when further "cleaning" becomes useless since it does not add enough to the whole picture to even spend time on it.
What comes next depends on open discussion and collaboration.


Recently I was told by tzachs that, quote:

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.

I actually disagree to this for following reasons:
1. JJS's branch contains ports for several platforms. These may have different issues that never existed in Windows version. I doubt anyone can tell when they all are well tested and fixed.
2. Current 3.2.2 version itself is still in BETA stage (at least that's what editor tells when I open it), and hence should be tested and maybe fixed on its own.
3. Having number of branches each for certain aim (e.g. basic functionality, editor, ports, etc) is not a problem so far as they all originate from same root and exchange code regularly. There's no reason to "kill" these.


What is the practical suggestion?

A. Take existing 3.2.2 code and officially (with notice on site homepage) release it as an open BETA (with warnings to have game backups etc). Mind this, you can do it right now.
If there are errors, fix 'em.
If there are suggestions to the Editor functionality that does not require core changes and big work, implement them.
Polish the whole thing and release as 3.2.2.
Make the branch for future Editor development from here. All the new editor features that do not require changes to engine are implemented and tested in this branch first. After that they are copied to other branches (see below).
If there's a suggestion that requires changing both editor and engine, then wait for engine changes coming from other branch, or make editor part as a "carcass" then wait for engine changes.

B. After 3.2.2 is released, merge everything made for Editor to JJS's branch. JJS's branch so far had literally no changes to Editor, so that won't be problem a single bit.
Ask JJS to define some kind of "checkpoint", a date for "big release", and help him (if possible) to reach a stable Windows version and stable or relatively stable versions of other ports.
No new features are to be added to the branch at this time.
When time comes relase public BETA first, then new official version, call it, I don't know, 3.3 for instance.
Make a branch for future ports development from here. All the porting, including maybe even Windows system-specific changes, should be made in this branch. Every time a stable stage is reached, this branch will share its code to others.

C. Meanwhile the refactoring branch will be worked on, gradually changing from simple code restructuring to starting implement new engine features.
It will get the Editor code from 3.2.2 branch first, then "Editor" branch. It will share stable, tested engine code with Editor branch if such necessity is met.
It will get the ported code from JJS branch first, then "Porting" branch, and similarly, give back stable core code so that porters could check it for portability issues and add some fixes, tweaks etc.

Finally there will be Main branch, created right after 3.2.2 release and branched from one, which should not be worked upon at all (except for, maybe, manual and packaging fixes).
As soon as any of the previous three branches reach stable stage, it will get a code from them. It does not really matter in which order. It may get, like 5 changes for Editor and none for Engine. Yet that program will be stable and ready to be released any moment if wanted.


That's it.

If someone thinks I have no right to suggest things this way, then find the one who does have the right, drag him here and make him read this and state his opinion .

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.

I must disagree on what you say about "chaos". I don't think the situation I mentioned will necessarily cause chaos; it won't if the criterias for feature implementation are defined (i.e. what is allowed to go where).

But what I would really want to know: every development has certain goal. Was there any goal defined for the next official version (aka SVN Main)? Was it reached? If not, who continues to work on that?
Same for dev 3.2.2. What were your goals? Were they reached?
I am asking because I can hardly understand what's going on there, or rather why nothing is going on there.

I would like to also hear others on this. But from my position, that is - based on what I see and know, - it would be more logical to follow this release pattern:
- test and polish dev 3.2.2, and release it as 3.2.2; if there are any features added or fixes to engine and/or editor they are to be also merged to JJS's branch afterwards;
- finish, test and polish JJS's branch and release it as, for example, 3.3 (we could call it "AGS portable" or something);
- merge everything from JJS's branch into refactored branch and continue to develop it; perhaps release it as some 3.3.1 or 3.4 as an "experimental" release first, before real serious changes are made.
But that's a mere suggestion. I am still lacking understanding of everyone's plans...

If at some point we want to make up different projects (AGS iOS, AGS Linux etc), please let me know.

Should there be a differentiation between development branches?
If I understand this right, there are at least three:
SVN branch (3.2 something)
JJS branch with ports which is obviously far away from SVN
my branch with refactored engine, which is - so far - about same program as JJS's, but with additional risk factor.

Now, if people find bugs in one branch, they won't be necessarily applicable to another.
And yet there's a question about feature requests. Consider something was asked to be added to AGS (editor or engine), where should it be implemented? I think this should be discussed a bit further.

As a matter of fact, here is probably Janet's repo
https://github.com/jeancallisti

Huh? I haven't written a line of code yet! Planning to start next week.

Erm. Looks like I was mistaken after all. Jean Callisti has "(monsieur xx)" alias (https://github.com/jeancallisti)
But it was funny coincidence - JanetC, Jean Callisti...

What about accepting different scripting systems providing different computer programming approachs? This way, game developers would choose one of them based on their experience or personal preferences.
<...>
If the scripting system can be hooked up to produce an AGS bytecode compilation, then there would be no problem to give it as an option at all.
<...>
After all, those scripts are going to be converted to bytecode by the AGS compiler.

Personally I like this concept in general, although at the moment I have little idea how scripts are compiled and run in AGS and what would it take to allow something like that; I haven't had much chance to investigate this in detail.
What is being proposed here is very similar to how MSIL works.
However, there are two questions:
a) should we actually care about making such a wide variety?
b) who actually is supposed to be responsible for making and maintaining various compilers? I don't think it should be AGS team, at least not the core team.

If the internal language specifications are made open (they are open already de facto, since source code is open), literally anyone can make his own compiler and programming language for AGS.

Just how many rooms you have?
anyway

Basically you need to:
a) remember coords of the room player exited, and the direction he went.
b) use these values when changing room.

I would suggest writing a function for that. That may be put into GlobalScript or separate module, depending on what you like more.

Sort of this:
In the GlobalScript.ash:

Code: cpp

enum ExitDirection
{
   // (or East, North, etc - depending on how you like this more)
   eExitDirLeft,
   eExitDirRight,
   eExitDirTop,
   eExitDirBottom
}

import function ChangeRoomAutoCoords(int new_room, ExitDirection exit_dir);

In the GlobalScript.asc:

Code: cpp

function ChangeRoomAutoCoords(int new_room, ExitDirection exit_dir)
{
   // put here coords of desired room borders (depends on your game really)
   int roomBorderLeft = ...
   int roomBorderRight = ...
   int roomBorderTop = ...
   int roomBorderBottom = ...

   int lastRoomX = player.x;
   int lastRoomY = player.y;
   int nextRoomX;
   int nextRoomY;

   if (exit_dir == eExitDirLeft)
   {
      nextRoomX = roomBorderRight;
      nextRoomY = lastRoomY;
   }
   else if (exit_dir == eExitDirRight)
   {
      nextRoomX = roomBorderLeft;
      nextRoomY = lastRoomY;
   }
   else if (exit_dir == eExitDirTop)
   {
      nextRoomX = lastRoomX;
      nextRoomY = roomBorderBottom;
   }
   else if (exit_dir == eExitDirBottom)
   {
      nextRoomX = lastRoomX;
      nextRoomY = roomBorderTop;
   }

   player.ChangeRoom(new_room, nextRoomX, nextRoomY);
}

export function ChangeRoomAutoCoords(int new_room, ExitDirection exit_dir);

Then call it from room script like:

Code: cpp

ChangeRoomAutoCoords(# of room, eExitDirLeft);

This is utterly amazing. The graphic style is so original, I simply cannot remember I've seen anything like this in any other game, either AGS or not. Probably reminds me some surrealists art...

I wish you best luck with the project.

I cannot believe I am actually posting here, but...

A real man also knows where the quick load key is at all times. 

A real man also knows

Spoiler

IDDQD

[close]

And something to stay on topic -
Icey, I haven't seen your threads for about a year or so (I wasn't on forums), your drawings have really improved!
I read through this thread (yeah, I seriously did that) and I cannot understand why, why can't you just look for someone to script some small game for you while you focus on graphics? I just don't get it.

Have anyone ever mentioned such idea as using the winner of previous competition of different type as a reference? By winner I do not mean AGSer but the piece (art, music etc) that won the award.

Consider: someone makes a great background in the "Background" competition, and for the next "Music" competition participants should write music for that background. Or "Writing" competitors should write a story that takes place or somehow connected to the location on the background.
I a while a piece of music or writing could be taken as a reference for making background pic.
Same for sprites, animations etc.

Found similar suggestions:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=27157.msg583545#msg583545
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=27157.msg554968#msg554968

Btw, that reminds, me, I am totally sure some time (months? years?) earlier I've seen ProgZmax proposed to make every game object (Character, Room Object, Inventory Item, etc) inherit from some base parent "entity" class and support dynamic creation. I remember that because it is what I would like to see in AGS some day too.

"Some day" is a key word here

Ability to export views and any other resources not currently supported, adjust current exports to export relevant views with them (in the .chm, etc).

That is rather an Editor feature.

More dynamic limits, eventually phasing out static resource limits entirely.

This is not difficult to make right away, just need to put normal utility classes into use. I believe monkey_05_06 will do that eventually.

Well, I made this as a small experiment. I wrote a separate output "system" as a possible substitute for existing functions.
It may be found in the "feature_dbgoutput" branch here:
https://github.com/adventuregamestudio/ags/tree/feature_dbgoutput
Check that out (in both meanings ) if you are interested. Actually I would like to hear some comments.

Idea was to have a simple subsystem meant for outputting text messages for debug or user notification purposes.
Output is being controlled by verbosity settings (at the moment they are hard-coded, but I supposed they should be read from config or command line).
Verbosity is defined as flags:

Code: cpp

        VERBOSE_DO_LOG          = 0x0001, // do log (otherwise do not, C.O.)

        // Debug reason is for random information about current game state,
        // like outputting object values, or telling that execution has
        // passed certain point in the function
        REASON_DEBUG            = 0x0002,
        // Notifications are made when the program is passing important
        // checkpoints, like initializing or shutting engine down, or
        // when program decides to make a workaround to solve some problem
        REASON_NOTIFICATION     = 0x0004,
        // Warnings are made when unexpected or generally strange behavior
        // is detected in program, which does not necessarily mean error,
        // but still may be a symptom of a bigger problem
        REASON_WARNING          = 0x0008,
        // Handled errors are ones that were 'fixed' by the program on run;
        // There's high chance that program will continue running as normal,
        // but message should be maid to bring user or dev's attention
        REASON_HANDLED_ERROR    = 0x0010,
        // Unhandled errors are errors that program was not able to fix;
        // Program *may* try to continue, but there's no guarantee it will
        // work as expected
        REASON_UNHANDLED_ERROR  = 0x0020,
        // Fatal errors make program abort immediately
        REASON_FATAL_ERROR      = 0x0040,

        // Convenience aliases
        REASON_FUNCTION_ENTER   = REASON_DEBUG,
        REASON_FUNCTION_EXIT    = REASON_DEBUG,

        REASON_NOT_DEBUG        = 0x007D,
        REASON_WARN_ERRORS      = 0x0079,
        // Just print out the damned message!
        REASON_WHATEVER         = 0x00FF

System registers a variable number of "output targets" - objects of classes, which implement IOutputTarget interface. These may be newly created classes or any other preexisting class that was extended to become IOutputTarget implementation. For example, in this branch I made AGSPlatformDriver its implementor.

There's a general verbosity setting that is used to tell what types of messages should be completely ignored during game run, and each output target has its own verbosity setting that is being checked after general setting.
Print is made by ALL output targets that pass verbosity check. That means you may have, for example, a file output for printing out only serious errors, and console or editor debugger output for printing both errors and some minor debug notifications. You may even have two file outputs - one for general logging (some 'debug.log'), and separate one (original 'warnings.log') for printing only serious errors, and so forth - any combination of these.

Basically you register them like this:

Code: cpp

    out::add_output_target(TARGET_FILE, new Engine::out::CRawFileOutputTarget("warning.log"),
        out::REASON_NOT_DEBUG, false);
    out::add_output_target(TARGET_SYSTEMDEBUGGER, AGSPlatformDriver::GetDriver(),
        out::REASON_WARN_ERRORS, true);
    out::add_output_target(TARGET_GAMECONSOLE, new Engine::out::CConsoleOutputTarget(),
        out::REASON_WHATEVER, false);
    out::add_output_target(TARGET_FILE_EXTRA_TEST, new Engine::out::CRawFileOutputTarget("ags_game_debug.log"),
        out::REASON_WHATEVER, false);

There's a common function for printing simple message with given "reason", as well as bunch of convenience helper functions for more user-friendliness.
The output is made simply like:

Code: cpp

    out::fprint("Debug system: testing!");

    out::debug          ("This is a debug message, p1 = %d, p2 = %f", 1, 2.0);
    out::debug          ("Function name", "This is a debug message, p1 = %d, p2 = %f", 1, 2.0);
    out::notify         ("This is a notification, p1 = %d, p2 = %f", 1, 2.0);
    out::notify         ("Function name", "This is a notification, p1 = %d, p2 = %f", 1, 2.0);
    out::warn           ("This is a warning, p1 = %d, p2 = %f", 1, 2.0);
    out::warn           ("Function name", "This is a warning, p1 = %d, p2 = %f", 1, 2.0);
    out::handled_err    ("This is a handled error, p1 = %d, p2 = %f", 1, 2.0);
    out::handled_err    ("Function name", "This is a handled error, p1 = %d, p2 = %f", 1, 2.0);
    out::unhandled_err  ("This is an unhandled error, p1 = %d, p2 = %f", 1, 2.0);
    out::unhandled_err  ("Function name", "This is an unhandled error, p1 = %d, p2 = %f", 1, 2.0);
    out::fatal_err      ("This is a fatal error, p1 = %d, p2 = %f", 1, 2.0);
    out::fatal_err      ("Function name", "This is a fatal error, p1 = %d, p2 = %f", 1, 2.0);
    out::fnin           ("Function name");
    out::fnout          ("Function name");

    out::fprint("Debug system: end testing!");

The code is not final, ofc. Main issue is unsafe usage of string buffers, and also limits made by using static array, but this would be fixed as soon as utility classes are implemented.
I also may have gone too far with namespaces . On other hand the whole thing could be converted to the class in a matter of an hour.
Currently functionality mimics original AGS logging (file and writing to game console; btw it's funny I don't remember ever seeing that.... :/ or maybe I forgot how it looks like).

What do you think?

Is it possible to make a scaled-up picture appear when game's screenshot is clicked in the game database?

One thing I still want to see is the ability to have a script for every GUI, Character, Object, Inventory Item, etc. With a master script for each type.

I give you my full support on that wish! (morale support for now )

Notice how I made "say" a lowercase? Isn't that the programming standard? That's always confused me when I started with AGS. Classes, Interfaces, etc should be first letter uppercase, with methods and variables being first letter lowercase.

I guess this is an "endian" question.
All Microsoft libraries (WinAPI, MFC, .NET), as well as Borland Delphi (VCL) follow "capital letter" policy.
Meanwhile unix and cross-platform libraries show tendency to "small letter" policy.

As a matter of fact, it looks like the most recent commit was only a few hours ago, with a sample config file for running the iOS port.

As a matter of fact, here is probably Janet's repo
https://github.com/jeancallisti

Unless it is someone else with similar name... 

Well, the fact that such discussions appear could mean only that something is not right with organization. And in this context such posts serve their purpose right, whether everything that was written there is correct or not.

What I mean, it is not always important how the discussion started, important is that certain questions need answers.

Personally I try not to dive into discussing things I know not much about, or something that depends on outcome of other more urgent problems. Hence I am not going to write long posts here about Allegro or scripting language improvements, etc. There are people around who know better about that so they'll do. You may call that philosophy,... or maybe sheer pragmatism

I am totally sure that there should be an announcement made to the users of AGS, that would explain situation in general. Sooner or later people will start to wonder what's going on, and it would be impolite to make them read all those verbose threads Besides you may never know if a newcomer with skills would like to participate in development.

[Di Perla]

I know this is a long read and I know this has been discussed to a frustrating degree

Hah! Basing on my own experience, frustration generally comes from seeing everybody speaking of plans, but having no idea on what conclusion those discussions resulted in neither who is actually working on bringing the plan to life. It is especially tough for newcomers or those who did not track everything from start (e.g. http://www.adventuregamestudio.co.uk/yabb/index.php?topic=46270.0)

No more idea's, no more planning who is going to do what.

Now, that's a decision! It's a bit funny, I am getting this lesson for the second or third time in last year or so: if you see that everyone is hesitating - do it yourself. Even if you fail, others will see your example and give a hand.

But - closer to the topic.

Di Perla, you've actually raised a very important question. I may be not an ideal programmer , but I have an experience in software development, and I've "seen things", as some use to say; I've seen projects being screwed up because people who wrote and maintained it forgot what they are doing and what the program is supposed to be.

It is impossible to make a successful project without explicitly defined idea and concept.
It is possible, but actually not recommended to make a project without an accurate design document, which would state what we are doing, why we are doing this, and what our program supposed to do.
And last, but not least, people should understand that no program can and should be universal. There's always a temptation to add this brand new feature and that additional functionality, and to extend the program core god knows where; I know this feeling too! but one should learn to restrain himself.

There are other guys who are making a game engine with other properties, based on other technology (newer, advanced, name it)? Good for them! Haven't AGS had its own niche in game-making?
AGS is a tool, and as a tool it should be aimed for certain work, result and user.


Regarding "Development rules".
1. I believe there is a way to hide Allegro behind a thin wrapper, like an base interface for example. I am not suggesting to switch Allegro for anything else, but that will give an opportunity to do so in uncertain future, if one would like to do so badly.
3. I actually do like your idea to separate Engine and IDE teams. There are people who know C++ more, and those who know C# more. Plus, implementing runtime functionality and making a proper user interface are much different tasks and not everyone is able to do both on high level.

A side-note: I am happy you placed me in your list but I am no "Porting-guy". Unfortunately in my work as a programmer I mainly focused Windows; I did wrote couple of apps for Linux, but I used Qt library, which hid most of platform specifics.

Are you a programmer?

Are you?
Sorry, but I wanted to ask this for too long

What's your background in this? Are you making a poll or wants others to totally accept your words because are blessed by God

From what I know, he is a long time member of the community. And mind you, people here do not accept anyone's words easily.

Regarding strings, please please please keep in mind to make the API Unicode compatible (UTF-8, presumably), so that one day we can support more than 128 (or 256) characters.

It's good you mentioned that, it seems I forgot about this completely  At the moment I don't know how much problematic would be to start using wide strings in the engine, especially in the light of script system and backwards-compatibility. We need to check that out.

In any case, aren't there string libraries out there already? Not much point reinventing that particular wheel, is there?

There *may* be portability issues, plus std::string (as well as STL in general) generates a lot of code, as was mentioned in the thread monkey gave a link to.
But I am sure there should be a good free string library somewhere in the web... I am wondering if monkey is looking for one or wants to write that himself no matter what...

To be completely honest, string and array classes are not so difficult to write, if you aim for practical simplicity and not some uber-universal classes.

Well, as being said

a char[] has to have a size defined

In other words, that would work only when compiler can determine array size on its own.
This would be useless for char pointers when it is unknown what do they point at.

Also, I am not sure, how does this relate to a string class? String class is usually supposed to store string length (at least I think it should).

I have this proposition: make a simple and robust string, vector, etc classes. I my opinion defining their interface is more important at the moment, for implementation could be optimized and extended in future if wanted, but interface changes will require rewriting lots of code which uses them.

I should underline, that, in my opinion, a problem of AGS code is not only that it is uses unsafe arrays and strings, but also that it usually makes most of operations with them in place (e.g. string copying), thus increasing code size and repeating same simple algorythms over and over again all around.

Lol, I did all this wrong. For some reason I thought I should drag that human silhouette icon to the map, but it appears I should simply double click at desired point

I don't know if this is a forums problem or google maps one. But I cannot understand how to save my location on the map in my profile settings. I can zoom in, place the marker, then a panorama shows up with approximate address displayed. That's ok. I copy that address into input box in the top-left corner of the map window, and hit enter. Page updates and there's "Your profile has been updated successfully." message. But when I check the map, the marker is on the place it was before (showing my location somewhere in the inhabited woods or something ).

Can somebody please explain how this thing works?