Messages

Apparently some people were encountering a bug that was preventing them from finishing the game.
It's been fixed. Get the finishable game here : http://www.adventuregamestudio.co.uk/forums/index.php?topic=50034.msg636483592#msg636483592

[Version 2.0 : here]

Version 2.0 : here

We corrected the bug that was making it impossible for a few people to finish the game.

my background is in User-Centered Research, and (simplifying somewhat) one of the basic insights of that discipline is that you're more likely to come up with a good design by going out and listening to the problems users are having, than by abstract contemplation.

I understand better where you're coming from, now.
OK then, in that case, the questions asked by CW are a perfect starting point: targetted users and main features offered.
Then maybe we could produce some Editor mockups? Not for eye candy or to be taken as actual specs, but for people to point out what features they think should be there and are obvisouly missing from the mockup.

- What kind of system/engine do you want to get done?
- What kind of users is it aimed for?
- What kind of general features should it have?
- Do you want it to be extensible, and which way?

> System : same as now. An Editor that's easy to install, and distributable games. Easy to use. Not necessarily very optimized, but fun.
> users : same as now: the niche of old-school point n click lovers. the people who used AGS so far should feel comfy with the new one.
> general features: same as now, but with the ability to be pimped up, to, let's say, something like the Runaway series -- (and possibly the Telltale Sam&Max series, but with plugins). Also, make collaborative work easier.
> extensible: like now, with plugins and stuff, but "more naturally". By that I mean: Spend less time coding weird object arrays and half-featured guis. Most of the stuff should be handled internally in a very abstract way (e.g. characters extend entities just like inventory objects do), a serializable way (clean programming and retro-compatibility, with proper data structures), a vectorized manner (e.g. no more obsolete pixel-based pathfinding), a 3D approach, even for 2D (e.g. 2D sprites are a billboard, which immediately enables 2.5D, but the regular user doesn't even know)

He's turning his head unnaturally. You usually don't look from side to side like that when you walk.

[The primary target is to make the code maintainable and expandable, which it is not anymore [or at huge costs].]

The big misconception in this discussion is that some people believe we want to ditch AGS to make 3D games bullshit. Nope.
We still want to make mostly [at least] old school point-n-clicks with AGS. "At least" means there must be room for more advanced stuff, but that's up to the community. The primary target is to make the code maintainable and expandable, which it is not anymore [or at huge costs].

=====

I think the perfect library to build upon for a proof of concept is Ogre3D, because:

- unlike Unity, it's free and open source. It's the heavyweight "graphics and more" engine in the opensource world.
- it's very much alive and keeps evolving quite cleanly along with new technologies. We can get all the support we need from their community. In 10 years it's still here.
- it's multiplatform
- it's just the right level of middleware: graphics, BUT ALSO input, sound, etc. Just like DirectX or OpenGL, but several layers higher.
- Perfect for AGS: it allows scripting : C#, Lua I believe, etc.
- Perfect for AGS #2: it's object-based, configurations-based, tree-based. It means we can mimic the tree-structure of an AGS project very naturally into the Ogre3D code.
- several people have developed RAD interfaces or Editors upon it. It's pretty much the AGS Editor already ready for you.

====

I find Unity very cool but I really don't like the idea of big commercial engines that can change their licensing policy overnight.

I'm not sure what else you might be confused about beyond that.

Nothing. Yours and Ghost's explanations were perfectly clear. Thanks guys!
For example I never realized that speech had a separate status because of the volume drop when someone speaks. Also, I thought that channels were just a technical aspect of sounds playing simultaneously (you may have up to that-many channels available, no more), but I didn't know they were useful for volume management of sounds of the same type.

It's all much clearer now. Thanks again.

[1. sounds types:]

Could someone either direct me to a place where it's explained how the new sound system works (not in terms of scripting or channels, but in terms of concepts: 1. sounds types: music, ambient, etc. 2. volume management) ,..or briefly walk me through it?

I've never been very familiar with the old system either. I just new how to play a music, or a sound, and repeat them, but I never knew how to control the volumes of sound and music separately, etc.

the question is : do you own an Oculus Rift to go with it?

[Obviously,]

Obviously, only the people who think they know about the topic should vote. Snarky, you're always so negative about everything. Most people won't care at all, or have no idea what it's about, so they won't vote. Why would people give their opinion just to sabotage the debate? And the vote is not so formal and strict. It's just taking the decision now that at some point we stop arguing, and we decide.

We don't know yet who will do it, so there's no point in saying "it's those who do it who decide". the community needs to decide, and stop hitting again and again the glass ceiling of "which libraires should be used".

======

For example, here is a fictional scenario:
Which library should be used for graphical routines?
- Allegro
- Ogre3D
- Unity
- just DirectX or OpenGL
(yes, yes, I do know that they're not on the same level, middleware-wise).

We discuss. Then at some point we call for a decision, and everybody (involved) names his favorite candidate.


If the libraires are decided beforehand, then there's room for someone to make a proof of concept, without the risk of telling him: "sorry, you did something very cool, but on the long run we think the libraries you built it on suck, so your awesome embryo of a new AGS can be immediately thrown to rubbish".

[I think we must take a strong decision:]

In other words, how do you (all of you who favor a new start) respond to the Joel on Software article?

Aahhh. I remember this article. And I disagree . I've seen too much bad code, I think.

The thing is that this article doesn't apply here :
- we don't want to do the code from scratch, because we'd use some widespread libraries (graphical routines, etc.)
- we don't switch entirely from the "old" ags to the "new" ags. There would be a period of transition, with the two of them being developed at the same time.

I want to say that, in my opinion, the choice of existing libraries and or framework is essential.

That's where the discussion stalls every time. I think we must take a strong decision: a forum thread with several candidate libraries for each key part of the Editor and Engine (RAD, script parser, graphical routines, etc.). Like, one table per component, with serveral entries in each table, one for each candidate library.
Then we discuss. Then we vote. And then the people who volunteer for rewrite stick to that.

would not that be better if the ScummVM version would become the leading interpreter for running original AGS games, while interested AGSers could make a completely new engine, free of old ties, not needing to be backwards compatible?

That's the most clever thing I've heard regarding AGS and ScummVM getting closer to each other.

selmiak this is purely a Windows question!
You're making clippy cry tears of blood.

Watch out, because not thinking of not pushing the button is almost like thinking of pushing it!

I started playing it but there's no way to save (or is there?). Since I had to interrupt my game, I quit and never went through the hassle of doing the first part again.

[WHICH]

Spoiler

Not push WHICH button?!??!

[close]

Because you must "not push" it, then mathematically speaking it's every button in the universe. Are you up to the task?

I can't give an estimation unfortunately.  You can add the flag manually for now I guess.

Sure, will do. Thanks for the answer. Please, it would be cool it it weren't too long -- I'm not really interested in the new features, but that flag is important for our compilation/releasing process, to avoid a lot of human operations and human mistakes.

As you probably know, diff and patch are very common tools in the Unix/Linux world.
They're less used in the Windows world, but there are some ports, some of them with a frontend.
So it's totally feasible to release binray patches for a game using such tools.

The only obstacle is the long research phase, to make the patch deployment as user-friendly as possible. Probably a batch file would be enough, but if something goes wrong, good luck to remotely troubleshoot that, with a horde of frustrated gamers after you !

In case it helps : http://www.adventuregamestudio.co.uk/forums/index.php?topic=33448.msg617692#msg617692

@abstauber : Additionally to what has been said earlier, In AGS, you must also consider the time required to access the memory cell of an array (the engine computes its position). In large arrays it can be slow, if I recall.
The only good solution in AGS performance-wise is to do the test yourself: do a function with "noloopcheck" and make it run on 100,000 entries. You'll see what's faster.

But as Wyz said: a big factor here is your algorithm's complexity: if many points are active, then testing the bool is more expensive. Otherwise, the other solution is more expensive.