A problem with "limit-breaking" engine

[Crimson Wizard]

I think I must tell about this, because it depresses me very much lately.
I made a very bad and rushed decision when I started to remake engine further: I continued to use the "partial upgrade" method by slowly changing parts of engine one by one, ensuring backwards compatibility working after every step, instead of writing essential parts anew and carry over compatibility later. Not only it took me more time working like this (because I had to break my head and make hacks after every change), but I now ended with a pretty ugly workarounds.
This can't keep going same way (not only technically difficult, but also psychologically exhausting for me).

However, redoing it right will take more time. Not only that, but, - let's put this frankly - I am quite tired now and can't promise I'll do this all soon. Perhaps I just need a change and forget about engine and this made up pressure for a while.

Therefore, this question is very important for me: is it worth to release this "raw" (or "alpha" if you like) version, forcing it to work by few more hacks? Are there people who would like to have new features regardless of risks? Assuming that I will be making few more fixes to support this "temporary" version.

The features I am speaking about are:

Spoiler

- unlimited number of state-saving room (max room count is still 999) and ability to select whether room is state-saving without setting ID > or < 300;
- unlimited number of dialogs and dialog topics; also option text of any length (not that it was important though)
- unlimited number of controls on gui; also Label/button/list text of any length;
- unlimited number of mouse cursors;
- unlimited number of room backgrounds;
- unlimited number of room objects;
- other room items are potentially unlimited too, but there is a problem with Editor UI lacking way to set their number; however I could, for instance, increase region/walkable area/walkbehind limit to match number of hotspots (50).
- unlimited number of custom properties; a way to change property value at runtime;
- unlimited number of overlays;

[close]

[RickJ]

Therefore, this question is very important for me: is it worth to release this "raw" (or "alpha" if you like) version, forcing it to work by few more hacks?

I would say no, it's not desirable.  Your AGS time is far too valuable to the AGS community to be wasted on, as you describe, a flawed methodology.  This has happened to me many times and have found that the best results are achieved by taking a fresh look and trying an alternative method.

Are there people who would like to have new features regardless of risks?

No doubt there are, peoples' desires are truly unlimited.  You can rest assured they will never be satisfied no matter what you do.
--------

I always wondered if these limits couldn't be specified in the editor's "Game Settings" or similar section.  There would still be limits but they could adjusted according to each game's needs.  Not nearly as automatic as truly unlimited but also perhaps not nearly as disruptive of the existing code base.

Open up some of the limits that are currently causing pain and leave the rest for the next go round would be my advice.

[Billbis]

Open up some of the limits that are currently causing pain and leave the rest for the next go round would be my advice.

The only thing I would benfit would be this:

a way to change [custom] property value at runtime;

Other limits do not "cause me pain". But I will certainly not choose an AGS version that allow runtime modification of custom property "regardless of risks". I'll rather looked carfully at what those risks are. 
Also, I support RickJ:

Your AGS time is far too valuable to the AGS community to be wasted on, as you describe, a flawed methodology.

So please, do only things that won't disguss you from contributing to AGS.

[Sslaxx]

It's a similar technique to Inform 6. It had limits, but those limits were all variables that could be altered by the coder if necessary.

[Lt. Smash]

If you are really willing to do it, then the fastest and most convenient way will be to rewrite the engine from scratch. Completely forget about backwards compatibility. This way you can write it like you are used to it and there are no limitations. Most of the features you will be able to easily convert from the old engine code, others may be more difficult.
If people want to upgrade to this new engine version, they may will have to alter some bits of their code to establish the same look and feel. If the project / folder structure changes, someone could write a simple project updater. I don't think this is asking too much from the users.

For the time now, you should just release what you have. Maybe just make limits to be changeable instead of entirely removing them, if this is easier.

Just my 2 cents.

[Ryan Timothy B]

If you are really willing to do it, then the fastest and most convenient way will be to rewrite the engine from scratch. Completely forget about backwards compatibility. This way you can write it like you are used to it and there are no limitations.

Before I got distracted with Unity again, this was actually something I was very close to seeing if I could attempt. I was looking into adding onto the MonoDevelop source code, or something similar, to be the backbone of the Editor. It would certainly be the easiest approach for me because I wouldn't want to deal with AGS editor code and the whole backwards compatibility nonsense, and especially AGS script - why reinvent the wheel. I even had a potential name picked out. Entertainment Studio (ES).

Anyway, this thread isn't about creating your own AGS but I couldn't help but comment.

As for releasing a version with potential issues, I'm not exactly keen on that idea. If you feel it's possibly broken you shouldn't feel pressured into releasing it.

[Crimson Wizard]

Sorry, I seem to become nervous lately.

I solved some thing that was troubling me in the engine and that seem to work ok, for now.

If you are really willing to do it, then the fastest and most convenient way will be to rewrite the engine from scratch.

That was never my intent. Although I see that may be tempting.
The biggest limitations are script and plugin interface, then the bloated feature implementations (because many different "styles" are mixed and intertwined in code).
However, having an existing platform has its benefits. It also serves as a "backup", so that if you can't find time to rewrite something you just leave the old code which may be bad but working.
Stopping doing small changes and do large ones instead (like completely rewriting certain functionality) may be a compromise.

For the time now, you should just release what you have. Maybe just make limits to be changeable instead of entirely removing them, if this is easier.

I think I'll do this, if it gets to usable state soon enough.

I was looking into adding onto the MonoDevelop source code, or something similar, to be the backbone of the Editor. It would certainly be the easiest approach for me because I wouldn't want to deal with AGS editor code and the whole backwards compatibility nonsense

What's wrong with the Editor? It does not have any problems with backwards compatibility. Most importantly, it does not need to support all the AGS Script tweaks, because it does not run it, only saves (and compiler is almost a separate program).
Maybe you mean engine?

[Ryan Timothy B]

Editor for trying to shove C# into it and having it debug/autocorrect. But yes, I mostly meant both.

[Khris]

No matter what you decide to do: your efforts are greatly appreciated!

I say: screw backwards compatibility. 3.2.1 is a stable, nice version, and people can always fall back to that; there are people around who still use 2.72 for the same reason.

As I'm sure you know, dirty workaround hacks are the worst, especially if at some point other people are going to work on the code.
And rewriting things from scratch can be tempting, but the additional workload can be astronomical, or at least much more than previously thought.

[JanetC]

I've never had particular problems with the limits in AGS. I could do with more room objects sometimes, but I just recycle old ones if I need more.