Messages

You might want to rethink Unity,

I don't know if you are addressing to me, but if I was to use another engine, that would be Defold. Not widely known, but proven, stable, fast, lightweight, and free.

What I also see as a problem in the long-run, is too much reliance on third party frameworks, at least for a serious project. Showing potential is one thing, how confident you can be about its longevity is another.

Yeah, I endorse all the efforts made by everyone involved for AGS to still exist. I also hope it will continue to adapt to modern technologies, while retaining it's character.

And I'm glad you focus on performance and efficiency. The engine already gives non-programmers an easier route for creating their game. Naturally, the more low-level mechanics are exposed as buttons and options, the easier it is for beginners to get the hang of it. But while the lack of knowledge can be more or less compensated by a helpful community, a poorly performing game is detrimental to both the creators and the players. This is not a complaint, of course, just a statement.

The current cons of AGS, perhaps from my personal perspective:

- Game editor is frankly subpar; user interface is often awkward and limiting.
- Game project source is difficult to read, let alone work with, outside the editor. Most of the game data is inside a big xml file, and rooms are saved in binary format so you cannot even look what's inside of them without launching AGS. Imported sprites are written into one big file, where again you cannot look into them or replace without running editor. This also makes parts of the project prone to file corruption: anything happens during saving the game may make you loose a whole room, or all of the sprites.
- For the same reason, it's complicated to work with AGS games under a version control tool (svn, git etc): as parts of the game are binary blobs, it is impossible to track the actual history of their changes.
- Lack of Unicode text support.
- Imperfect translation system, where translations may be complicated to update and easy to break. No true support for localizing other parts of the game rather than the texts: such as images, sounds, voices (you have to do this by hand, sometimes using workarounds).
- Building game packages for other platforms than Windows and Linux requires manual labour. No official support for gaming consoles.
- Scripting language is a mix of low-level and high-level concepts, but does not get any of these to the logical conclusion. So on one hand you cannot refer to plain variables and structs using their memory adresses, on another you have "managed" structs but the use of these is limited by incomplete syntax and unsupported features. It's like having bits of both worlds instead of one but complete.
- Script's implementation is slower compared to popular scripting languages. This won't be noticed if you have a regular point and click scene, but may quickly become a problem if you e.g. script a fast paced arcade sequence with physics simulation, etc.
- Most of the things may be only created at the design time. You cannot have dynamically created rooms or objects. This complicates working on anything that is not a standard point and click scene, and forces you to precreate almost everything in the editor, even if you need an object only for some temporary visual effect. If you want a "procedurically generated" scene or game, you have to precreate a number of dummy objects and reuse these.
- Game saves contain practically a virtual memory state, and may be restored reliably only if the game contains exactly same game objects.
- Lack of contemporary visual effect support: e.g. no GPU-based object rotation, no custom shaders, let alone any 3D effects. Any additional effects have to be scripted with the use of the pixel drawing (aka "software drawing") which is significantly slower.
- Engine is not well optimized for high-resolution games: the way it draws things, or loads resources, maybe works well with "classic" low resolutions, but not with higher ones.
- Abscence of debugging and diagnostic capabilities: you cannot tell what's going on inside the engine when it runs your game.

Sorry to resurrect an old thread, but which of these cons still stand in AGS now entering version 4?

This goes out of scope of what we usually plan for the engine.

You're referring to more walking directions, or just the distance thing?

You need to create a label on GUI, and assign a text to that label.

Got it, and it's now working. Appreciate it.

Awesome!

(Properly speaking it should also vary by distance, but that might be getting a bit too complicated. Perhaps if it was made dynamic, it would be possible to script it.)

Do you mean to gradually slow down the movement when walking up the y-axis, to imitate longer traversed distance when they walk further to the background? That would be great too. It would also make sense to work vice-versa and accelerate when walking down (forth) again.

Will you consider creating 8 more walking directions in the Views node? Meaning, three diagonals instead of one for each quadrant.

Thank you.

Thank you, Khris. As I'm not so acquainted with writing code from scratch, you surely help a lot.

So, trying to translate your guidance into how I see things in AGS 4.0, I created a new script module (left it as NewScript) and a new GUI (as lblDebug), then I set the GUI's PopupStyle property to Always Shown (persistent). It throws a complition error "NewScript.asc(36): Error (line 36): '.Text' is not a public member of 'GUI'. Are you sure you spelt it correctly (remember, capital letters are important)?" Also, by adjusting it to the walkcycle frames, in which part of the code will I have to copy the frame number?

I'm throwing in a feature request in the editor forum too, but I'd like to do this by code as well. It surely helps to learn.

Hello. So, is there a way to create more character walking directions than 8? And would that impact the performance a lot?

In the views section in the editor, every new loop after 7 is generated with a "no special purpose" tag. Can I assign code to these somehow, as to create 8 more diagonal loops (e.g. in degrees such as 22,5 and 67,5) for a total of 16? Even better, are there plans to support this directly in the editor itself?