Does it make any sense to develop AGS further?

Started by Crimson Wizard, Thu 13/04/2017 19:10:09

Previous topic - Next topic

RickJ

Quote...it may or may not help to know that many people feel like they've only made terrible mistakes and are a fraud every time someone expresses thanks.
I don't know about that but top engineers/programmers are never really satisfied with their work. They are in a constant state of learning by doing, the more they do the more they learn.  When you know more you are less satisfied with the work you did when you knew less.

Quote
I think the money thing keeps on coming up because it's how different people are motivated. ...
Everybody is motivated by money, the only question is how much.  The other motivation is self satisfaction which is, of course, priceless.


tzachs

Quote from: RickJ on Mon 24/04/2017 21:14:02
CW makes a good case that the AGS runtime (i.e. the engine part) has reached a point where further development is becoming impractical.  Others have pointed out the advantages AGS (i.e. mostly the IDE part) has over alternatives.  I have no reason to disagree with these assessments. Further, we have at last three new runtime projects, based on lua, C#, and WebGL, currently under development that do not have the same limitations as the current AGS runtime but lack and IDE.

So, we have a great IDE integrated with a runtime that is difficult to improve and becoming obsolete.  We have three newer runtimes under development without the current runtime's limitations.  One can only wonder if it would make sense to move current AGS development towards the possibility of the IDE targeting multiple runtimes?   

If one thinks the editor is good enough, then I agree, a focus can be made just on the engine while sticking with the existing editor. This is exactly what Scotch is doing, I believe, he mimics the engine's API precisely so you wouldn't have to change much in the editor to support it.

Personally, I don't think the editor is good enough. I agree that it has advantages over other IDEs (mainly it's focus on a single productive workflow), but in other ways I find it lacking: poor code editing capabilities, almost no debugging capabilities, no portability and also I think that pretty much all of it's UI designers can be improved as well (not to mention that the editor will need a lot of improvements to support the new engine features),
which is why I opted for re-designing everything and not just the engine.

RickJ

#122
tzachs, I went back and read your post and I find many of your editor ideas very attractive.  In my previous post I was just summarizing what I understood the consensus of this thread to be that AGS is easy to learn and a pleasure to use. 

I got the impression that you were doing the engine first and the editor later but perhaps I misunderstood you post or conflated it with others.   How far along is your editor?  How portable is C# with respect to Linux, Mac, mobile and web?

I was thinking in terms of an intermediate compiler output (similar to compiler producing .obj) that could be targeted to multiple runtimes (similar to traditional linker).  If we could define a standard api, intermediate language or whatever term is appropriate then everyone could design to that standard.  We could choose a common file format such as YAML, JSON, or XML and allow for both compressed and human readable forms.  This doesn't mean that development necessarily has to have an extra step between iterations.  A default or development engine could be defined in a configuration and the link or targeting process could be done automatically. Alternatively the editor could have an integrated engine and export to the intermediate form on demand if that would make development iterations were more speedy or efficient. I don't mean to minimize the required effort as there would surely be issues to resolve but in the long run it may result in saved effort.  It's a way of having a degree of independence between IDE and runtime.  It would make it easier to support future, not yet invented, platforms.  It would also be a way for you, scotch, colin, and the rest to collaborate and benefit from each others' effort.

Perhaps it would make more sense to apply such an effort to the editor you or scotch are planning than to the current  AGS editor.  The import thing I guess would be to capture the essence of "easy to learn, pleasure to use".  Btw, that could be a cool marketing slogan.  Just food for thought.

Crimson Wizard

#123
Quote from: RickJ on Tue 25/04/2017 05:19:05
I was thinking in terms of an intermediate compiler output (similar to compiler producing .obj) that could be targeted to multiple runtimes (similar to traditional linker).  If we could define a standard api, intermediate language or whatever term is appropriate then everyone could design to that standard.

This makes me recall an old qptain Nemo's idea about "Adventure game language", kind of "api" used to describe adventure game, which may then be interpreted by various engines as they see fit.

I would also like to add a note, that even if a global api does not exist, there is a still a chance to create converters from one data to another. Even AGS does that now to some extent, converting certain old game data into new supported form.

Peder 🚀

Quote from: RickJ on Tue 25/04/2017 05:19:05
"easy to learn, pleasure to use".  Btw, that could be a cool marketing slogan.

I like it!

tzachs

Quote from: RickJ on Tue 25/04/2017 05:19:05
I got the impression that you were doing the engine first and the editor later but perhaps I misunderstood you post or conflated it with others.   How far along is your editor?  How portable is C# with respect to Linux, Mac, mobile and web?
Your impression is correct, I have not started working on the editor (unless you count design), I'm concentrating on having an MVP engine first (and also working on documentation currently). Then I'll start working on the editor. C# is perfectly portable to Mac, Linux and Mobile. The engine already works on Mac (in fact, I do most of my development on a Mac currently) and Android, and I'm currently working on IOS, and then I'll work on Linux.
The web is another issue, unfortunately, and currently not easy for porting. The Mono team is working on supporting web assembly, though (http://forums.dotnetfoundation.org/t/wasm-asm-js-plans-projects/1947/2), so hopefully once that's released it will be possible to support web.

Quote from: RickJ on Tue 25/04/2017 05:19:05
I was thinking in terms of an intermediate compiler output (similar to compiler producing .obj) that could be targeted to multiple runtimes (similar to traditional linker).  If we could define a standard api, intermediate language or whatever term is appropriate then everyone could design to that standard.  We could choose a common file format such as YAML, JSON, or XML and allow for both compressed and human readable forms.  This doesn't mean that development necessarily has to have an extra step between iterations.  A default or development engine could be defined in a configuration and the link or targeting process could be done automatically. Alternatively the editor could have an integrated engine and export to the intermediate form on demand if that would make development iterations were more speedy or efficient. I don't mean to minimize the required effort as there would surely be issues to resolve but in the long run it may result in saved effort.  It's a way of having a degree of independence between IDE and runtime.  It would make it easier to support future, not yet invented, platforms.  It would also be a way for you, scotch, colin, and the rest to collaborate and benefit from each others' effort.
The alternative suggestion sounds much more viable, though it too will have a lot of limitations. Importing/exporting scripts between languages is not going to happen, for example. Also engine features will not map 1-to-1 so you will definitely lose information during the conversion. I'm not opposed of doing something like that in theory, but it's definitely a very low priority for me currently, top priority is build an MVP, release, get feedback and stabilize.

Quote from: Crimson Wizard on Tue 25/04/2017 09:47:28
I would also like to add a note, that even if a global api does not exist, there is a still a chance to create converters from one data to another. Even AGS does that now to some extent, converting certain old game data into new supported form.
Right, I already planned on my editor to spit up both code and json/yaml file. The code so that the user will be able to detach from the editor whenever she/he wants, the json/yaml for the actual UI designer. So using that json/yaml somebody would be able to convert to other formats (with the same limitations I already mentioned).

RickJ

tzachs, I had a look at the web assembly stuff and it looks promising.  Which GUI toolkit are you using?  Please let us know when/if the project progress past it's "secret" phase as some of would surely be interested in following along. 


JanetC

Quote from: Crimson Wizard on Sat 22/04/2017 15:46:10
The truth, that I has finally realized, or rather forced myself to admit, is that I am coward. The simple and terrible thing was that I was not brave enough to try something like, for example, scotch is working on right now. Even though I was supposed to, believed I should, and even was making plans about that.

Had I find bravery to do that, we could have a replacement engine for AGS years ago.

What was the result of my cowardice is 5 lost years, a wasted time and opportunities, both mine and yours. I feel like a greatest liar now, an impostor, who pretended that he is doing something good. Your community deserved better than that.

I cannot forgive myself for this, even when people tell me that I did well, that does not persuade me even a single bit, because in my heart I know that's not true.

Many have started new adventure game engines, few have finished. So maintaining a finished engine that people use every day and enjoy is very worthwhile. It's just as challenging as starting from scratch, because you must understand the code of others.

Plus, don't dismiss the "hive mind" of people who already know how to use an engine. If a person is just starting out writing games, AGS is well documented has a large and thriving community who can advise them. This is very important to new developers. It's lonely to use an engine that almost no-one else uses.

You mention feeling like an imposter - I do think that you should google "imposter syndrome" - this is very much a common affliction among coders.

tzachs

Quote from: RickJ on Wed 26/04/2017 14:44:10
Which GUI toolkit are you using?   
I wrote a little bit about my plan here:
https://github.com/tzachshabtay/MonoAGS/issues/137

The tldr; version: I plan on having the engine itself as my GUI toolkit for the editor (but it's not definite yet, I plan on trying it out and then evaluate how crazy it really is).   

Quote
Please let us know when/if the project progress past it's "secret" phase as some of would surely be interested in following along.
Well, technically the project has been available on Github from Sep 2015, so you can start following now :)
I plan on releasing documentation for the engine by end of next week which would hopefully help to understand how things work a bit better.

RickJ

tzachs, Perfect timing.  I'm about to embark on some C# stuff for my day job so it'll be like  killing two irds with one stone.

selmiak

#130
I stopped reading at the point where it said throw out all the tangled legacy code and start having fun ;-D
edit:
no wait, it said throw out backwards compatibility.

SMF spam blocked by CleanTalk