Messages

Hey ladies/gents

I've been working on Adore (my adventure game engine) and I'm currently looking at how to arrange animations.

AGS kinda works like this:

Views have Loops which have Frames which are references to Sprites.

In adore it's slightly different.
It's more memory efficient to store an animation in memory as a texture atlas like this:



So in adore we have:

AnimationSets which have Animations which have a Texture Atlas (which is taken directly from a file on the filesystem like all sprites in adore) and a list of Frames which contain the delay info.

Now, I know that some consider the whole View system of AGS to be a little archaic and unintuitive so does anyone have any suggestions as to how they would prefer animations to be handled?
What do you think of the idea of having a named texture atlas for animations instead of individual numbered sprites like in AGS?

There is an issue with 32bit surfaces on some integrated hardware. Abstauber reported this on Ever Beginning Tale when I released the source. EBT has no coding that should cause slowdowns but he reported single figure FPSs. Downgrading the surfaces to 16bit fixed the issue. I never followed up to find a cause

Godaddy will act as registrar on your behalf. Thats how i got leafsha.de

I would imagine that most of the particle systems handle alpha just fine. Nothing in the API has changed. Where we used to get pink fringes, now you won't.

The calculation and the looping in the script is likely to be the bottleneck here. As a lua script you could probably get 10 times the performance.

Theres no reason 320x2x0 should be dropped. The new system just needs to be resolution agnostic and allow the game maker to choose the filter used for scaling. We already have this to some degree.

If an adventure game is set in some environment other than plain old present day earth there is some world building to be done. Certain concepts need to be explained to the player and there's a lot of peripheral info that the player might like to be aware of but is not plot-critical.

My question is what good ways are there to give this information to the player? Long dialogue sequences (especially non-interactive ones) are rightfully frowned upon by players so how else can we explain things to the player without boring them and without requiring them to go at read some book in an in-game library or something.

[So]

Dualnames Meltdown #14

I know that I, for one, will be incredibly insulted that you removed some lesbian images from something. So insulted.

Sorry, I wasn't implying that you were attempting to censor. My choice of the word "police" was poor and ill-thought-out.

To clarify, I do think it was fully inappropriate and crass as I said. I thought that you were saying that it was homophobic to sexualise homosexual activities when one was not, themselves, homosexual.

I apologise deeply for the misunderstanding.

Some people (male and female) find sexual interaction between two people of the opposite sex to be, as you put it, "sexy".
To say its a "male gaze" thing is absurd. It's an opposite sex thing which in this case happens to be lesbian. Many women find gay men arousing (check tumblr). You can't police that.

I'm not defending dualnames at all. As I said I found it childish and in bad taste.

I dont think anyone was being homophobic here. The sexualisation of lesbians is crass and childish but it's not homophobic. Dualnames is not a bad person. Let's not demonise.

I've been annoyed at the appropriation of Eternally Us for stupid sophomoric shit from DN for a while. It's childish and the characters in EU were never intended as lesbians anyway. I mean it's literally a playground-level attempt at humour. ("Tee-hee, he said 'boobs'"). Get a grip, sir. You're like 25 years old.

Could you explain that a bit? Is the only reason you oppose libGdx that "scripting" would be in Java? AGS script already has structs, and a proper class system has been requested for a long time. I think there are pros and cons to Java as a language, but can't really think of any major code-writing complications it would introduce compared to what we have.

Sorry yes, I wasn't clear.

When you introduce a language (like java and c#) that has a mandatory OOP structure (*everything* is an object) you introduce all kinds of more advanced programming concepts and I think those concepts should be an addition or an option rather than something that one need know to use AGS.

I might be overstating the issue but I think a more conventional scripting language would be a better idea (Angelscript, Lua, something similar)

Also, Java is a huge language which might be a bit much for making a little fellow walk around saying things.

EDIT: I wasn't particularly averse to LibGDX. Only the class structure posted. We could use any number of scripting languages with libGDX as the host.

One of the really bad things about AGS is the format of the compiled games so the answer to this question is quite obvious to me.

This is the main thing that bothers me. Having a sort of pseudo, mixed, binary serialization makes it really difficult to make changes to the format.

Adore simply uses zip files, text files and the filesystem. Any data can be added to the format with a guarantee of not disturbing other stuff.

On the libGDX suggestion I disagree with that (although you'll find a post by me a few years ago suggesting pretty much the same thing). Adding a formal class system like that to what is, essentially, a hobbyist tool would be madness.

I am pro-rewrite. Or rather pro-drastic-change.

The editor could probably be salvaged but AGS is old not only in terms of its technology but also in its approach.
In a lot of ways it is built from the ground up to make retro games. It was built to emulate sierra and lucas arts games and it shows in terms of its architecture and its technology.

However, I do agree with Snarky that AGS is AGS and it's conventions are there because the people in this community like them and for someone to say "let's make AGS 4 completely different" does somewhat miss the point of a community.

With that in mind I think it might be best to make a competing engine. Something that attempts to emulate AGS but in a modern way. Essentially what AGS was to the old Sierra tools or SCUMM. Not a rewrite but rather a homage to the original. It would stray from AGS's vision in a lot of ways just as AGS improved upon SCUMM and its contemporaries.

I'll have something to announce soon on this, depending on rate of progress.

EDIT: On snarky's comment that AGS is a "huge beast". I disagree. It's huge in some ways because CJ doesn't use a lot of off-the-shelf technology and so maintaining the project has become arduous. Adventure games are very simple. It's not that complicated to replicate what AGS does with modern technology.

That sounds like a good idea to me.

It's absolute. Thats just how CJ stored it.

(Mod note: This discussion was split from this thread. â€" Snarky)

As I learnt the existing code better and about problems that were required to be fixed, I was coming to the thought that AGS is simply not suited for upgrade that everyone wanted. It appears to me that although it reached certain state with existing features and capabilities, it took more than 10 years to evolve into what you have now with the work of one man (Chris Jones), and it will take too much time to evolve further to the next "level" to keep up with the demands of the modern day game developers and game players.
Perhaps it could be better to start a new engine, back couple of years ago, built with completely different design in mind, to replace AGS, but it's too late for me to try that now, especially not alone, especially while other engines and frameworks appear - this makes me feel that my work is getting useless in the perspective.

I know my opinions on this stuff are rarely popular but I agree with CW on the matter of AGSs updateability.

I believe AGS is not suitable in it's current state to be brought into the 21st century for two main reasons.

1) the graphics stack is designed primarily to be software based. This is a consequence of it's reliance on allegro. The hardware accelerated support is very much tacked on the end and that's just not realistic for a modern engine and it's only going to get worse. It would be difficult to fix this because a lot of the API relies on direct access to the surfaces (DrawingSurface support for instance simply cannot be moved to a hardware accelerated system without breaking backwards compatibility)

2) The scripting language is slow and archaic and it would require a huge overhaul to fix. *I know, I know* I've been on and on about this for a long time so I will leave it at that.

However, I see no reason why we can't begin AGS 4. The work CW and his team did on 3.3 was outstanding and it fixes most of the trivial issues people were having like alpha support and other resolutions (in the other branch) so I think it would be perfectly reasonable to leave AGS 3 behind at this point and consider it as done as it can be in it's current incarnation.

In a lot of ways that's kinda sad but I think it's also optimistic to draw a line under something and start again as a community.

I know I speak for everyone when I say that I hope CW would consider being a part of that.

My personal favourite at the moment is Love (love2d.org).

I like love because it provides you with access to fairly advanced stuff (shaders, the open gl matrix and stuff) while keeping the API super simple and giving you sane defaults for all the stuff you may not need to touch.

I'm not sure what to think of unity. It's kind of a mix of both worlds but i'm not sure if thats a good thing or not. It's *very* structured but also it's quite suited to rapid prototyping. I think though that when making something larger in unity the rapid development aspects kind of fade away. It's easy to make something in unity but making something larger requires that you follow their structural design quite closely which i'm not sure is useful in the long term.