game-editor.com

Lately, I have come across an opportunity to begin the development of Game-Editor 2.
Reasons are:
- I planned it a long time ago
- I received a chance to do so, as I said
- There aren't any "good enough" 2D game engines or they are overpriced.
- I managed to deal with a 2.5GB game-editor project. A project so big
that game-editor was hardly succeeding to enter "Game Mode".
I decided that I should pause the project and create a new engine.
- Not only I, but many people actually do need a better editor.

Those are solely the reasons to start but in order to continue,
I would have to find motivation in you, the community of already grown
game developers, each with a sparkling talent and uniqueness.
That's why I am making an early (relatively) announcement.
We have a lot to discuss. Spam comments are going to be
deleted as well as placeholder comments such as:
"Finally", "Good work!", "Amazing", etc. I need this to be
an actual development thread, with opinion, questions, suggestions
and any kind of useful information in any form.

The new engine is going to represent game-editor in any aspect, and yet, the underlying libraries and frameworks are going to be completely different. Think of it like game-editor if it was constantly improved, all the way since its first release. I really hold on to authenticity, because game-editor have defined probably the best concepts for RGD across the variety of indie environments. Game-Editor 2 shares the philosophy for game creation with its descendant Game-Editor Original, but implements the editor interface by virtue of GTK+ which is the best cross-platform GUI toolkit available for the C programming language and utilizes ORX engine (framework) for the actual game rendering and in-game mechanics. ORX is the best (and almost the only) game engine that can be used in conjunction with C-GTK+. Moreover, it contains the power of every modern game engine out there (In fact, it exceeds them). GTK+ as a toolkit also comes with Cairo, a library for optimized vector drawing, gio for i/o including networking i/o, gobject for a slight object-oriented taste in C, glib thread support, abstract data and more. So to represent in one sentence - GTK+ORX Game-Editor 2021

I have discussed implementation details with the person responsible for the existence of ORX, which is actually a very powerful programmer with years of experience in the game development sector, working the most prestigious jobs as a game developer and author of the entirety of ORX engine. Additionally, I've discussed marketing for years, with my boss, Peter Krumins, CEO of "browserling" and other products. And now, let's get what is left in this community, merge it with ORX community and even GTK+ community (because this editor will also serve as a standard for GNOME applications) and every other game developer in the world, who wants their needs to be reflected on the surface of this upcoming game engine. That's right, this software will be inspired from everyone's needs, not just mine, which are already far beyond average due to my high-placed goals in general.

I've been working for two and something monthes already and I've established an Alpha release.
The development stages are going to be grouped in the following manner in respect to the versioning system:
1. Game-Editor alpha - current, that is, base interface, adding/removing/cloning actor, configuring actor, game mode and a good amount of editor features
2. Game-Editor beta (the next stage, which is rewriting alpha in a cleaner manner, fixing issues and adding more base features)
3. Game-Editor2 stable (same as beta, but tested by users and influenced by user feedback)
4. Game-Editor2 1.0b (Writing a custom C99 Interpreter, adding IDE and Script Editor functionality)
5. Game-Editor2 1.0 (first official release, includes windows and Android export binaries)
6. Game-Editor2 1.1 (adding a plug-in interface to the editor)
7. Game-Editor2 1.2b (adding context menu game logic handling for those unfamiliar with scripting)
8. Game-Editor2 1.2.1b (adding project management)
TBA

Some of the most notable features that will be added and are not found in Game-Editor Original:

• Hardware Accelleration
• Actor transformations - Scale, Rotate, Stretch, Mirror
• Real-time resolution change
• Networking support
• Joint mechanics

More sophisticated features:

• Shaders
• Particles
• FX
• Generators

The end of crashes, bugs and other issues.

This is the list of already added NEW features (that were not introduced in gE)
1. Scroll to game center keyboard shortcut
2. Auto actor naming
3. Extra preferences page with extra settings
4. Resolution numbering
5. Editor full screen mode
6. Selected actor bonding box
7. Selected actor pivot point
8. Dark theme
9. Extra game options page with extra settings
10. Show FPS Game Option
11. X/Y spin button controls
12. Paned window actor controls
13. Locked actors will appear greyed out
14. Ctrl+L lock actor keyboard shortcut
15. View actor custom width/height
16. View actor zoom
17. editor zoom to view zoom keyboard shortcut
18. Clone actor shortcut
19. actor custom width/height
20. actor info tooltips
21. view actor visibility at lighter game backgrounds
22. actor flip
23. actor rotation
24. Editor actor paint
25. Add animation
26. Sprite animating, better frames detection
27. Aniamte in-editor
28. "Smooth" option for animations

This is the list of some more features to be added:
1. Custom cursor
2. Dragging actor while zooming
3. Actor drag direction lock
4. Renaming actor
5. Guidelines
6. Cursor scale, rotate, stretch mode and keyboard shortcuts
7. Dragging actor on pivot point
8. Fading overlay when zooming showing zoom level
9. engine settings (experimental features, etc - FILEIO)
10. Monitor (/w command console to modify engine settings etc)
11. Loading on game mode (no instant window disappear, wait for orx window)
12. Use gallocator module
13. Actor snap
14. Transparent actors control pane
15. Reordering actor control sections

And this is the list of implemented features typical for gE:
1. Game Mode
2. Game Configuration
3. Preferences
4. Editor Game World
5. Zoom
6. Add actor
7. Remove actor
8. Clone actor
9. Actor movement
10. Actor control
----1. Navigation combo box
----2. Transparency
----3. Z-depth
----4. Add animation
----5. Remove animation
----6. Animate
----7. Animation selector
11. Actor locking
12. xy display
13. Actor cursor

If you really need a feature, but it turns out that you are pretty much the only one
that really needs it, it's okay, there are still some good news for you.
The plug-in architecture will allow you to write a plug-in with full-access to editor
components through an API, in C, without compilation or installations. Just by putting
the plugin.c in the plugins directory and the editor will do the rest. By the same mechanism
I'll be adding a "Simulation Mode", which allows one to edit the game while running it and
advanced sprite editor.

Donation and future pricing?
Now to the more delicate subject. I have no intentions to sell my efford for free.
I really don't want to die homeless. I have a nasty eye condition, which makes me
unable to work as much as I used to and working has been a challening fight those days.
I will need investment and profit to be able to maintain this. My life is quite expensive.
Programming is not easy, especially when you are into such a big project alone.
I just need support in any form. Without it, there is less guarantee that I'll be able to do it,
especially any time soon.
This sounds scary doesn't it?
Don't leave!
Yes, I was absolutely being uncompromisingly honest with all that, but remember that I said
that this will be the cheapest engine to use? Well, it is actually going to be FREE!!
Of course, I'll still need to make a profit from it somehow right? So what I'll do is
provide users with a monthly subscription of just 9$ to be able to export the game.
We only need to export the game when we are finally done with it, correct?
So you have absolutely no problem trying the engine, as it is, fully featured, for free.

Donation privileges
- Anyone who donates more than 1$ will have the privilege to test some non-official builds with all their features.
Those users will be credited and will be assigned with a "Donator" tag. They'll have a permanent
premium support and will receive real time progress information upon request.
- Those who have donated more than 9$ will automatically have a subscription, lasting for a
period equal to the amount they have donated. 18$ - 2 month subscription with a "Financial support"
tag.
- Users who have helped, may be invited to join "the team", which will give them privilege to
use every version and snapshot, without the need for subscription, but this will only
happen when and if I decide. They'll have the "Staff member" profile tag
- ORX developers have the same privilege with a "Developer" tag
...that is when I have a site.

Links
I just created this Patreon page: https://www.patreon.com/gameeditor2
and this youtube channel: https://www.youtube.com/channel/UCKeGRQ ... vzZFH9veww
and this for images: https://ale-s.imgbb.com/
and you can visist the #Game-Editor2 channel on ORX's discord - https://discord.com/invite/aC84aJJ
there you can find lots of videos, showcasing isolated features as well as more info
Ko-fi, if you don't find Patreon suitable for donations: https://ko-fi.com/gameeditor2
links will be soon updated, when I have more time.
Also, more announcements are going to be made, in different places.

It's been a while. Great to see you're still enthusiastic about Game Editor and that you are working towards brightening its future. Welcome back, I guess?

The project sounds promising. Am I correct in assuming that in its essence it's pretty much going to be a (heavily) Game Editor -inspired user interface for building games with the game engine in the back, ORX? Or am I missing something? Of course there'll naturally be some GE specific modifications and additions at least.

Anyway, I think using an existing game engine as the basis for the project is definitely the way to go, good call. That way you can fully concentrate on making the game development flow similar to original GE (but improved upon). Otherwise the first ~year or so (at least) would be spent building only the behind the scenes stuff of a game engine, something that can be very challenging and time consuming, especially when aiming for cross-platform both as a development platform and export option. So, by getting a head start by basing your work on ORX you're highly improving your chances of success. You of course know all of this already. I just like to 'think aloud' sometimes. And what else is important is that ORX is a new and vibrant engine with promising future.

While it is kind of sad that the original GE source had to be abandoned it is clear that it was the only reasonable option. Trying to revive an engine built on now obsolete technologies with a cluttered code base with little to no documentation would be an exercise in futility. This is the best chance for GE's legacy to continue.

And as I already stated in the Game Editor Discord - the monetization model sounds clever and fair.

Some thoughts / ideas / suggestions:

1. A better way to browse events:
One of the major problems I have with the UI of the original GE is that it makes it very difficult to explore someone else's projects and to try to understand how things work and relate to each other. Hiding all events behind multiple drop down menus with no way to keep multiple windows open simultaneously makes it essentially impossible to piece together how a large project works if it is made by someone else. And even one's own projects can be very challenging to return to after some time when one's memories of how the project was organized have begun fading.

Maybe there could be 2 lists of events. One that is global (not related to Global Code) and shows all events of all actors. And one that shows all events of the selected actor. The latter could be embedded to the Actor Control panel for example. These lists could have options for filtering by properties such as event type (both lists) and event actor (global list).

Example of the actor specific event list:


2. Tabs for Script Editor

This would allow keeping multiple scripts open at all times for quick access. Would also eliminate the need to close a script just in order to access another.

3. Advanced search functionality

It'd be great to be able to search for references to an actor / variable / function from all the scripts of a project. This would essentially eliminate the kinds of bugs that can be caused by forgetting about some leftover code used to test something. You'd be able to quickly troubleshoot bugs - the search could be used to find all pieces of code that can affect a variable's value, for example.

4. Support for external code editors
Users should be able to edit scripts in the editor of their choice - programming in a familiar environment allows one to be more productive. This would also allow settling for a simpler in-editor code editor, freeing resources for the development of other things.

5. Version control friendly project format
Original Game Editor stores all project data in a binary format, making it really difficult to tell what has changed between commits. This could be remedied by making the project file (.ged) a text file. Maybe a custom XML format or something. Well, XML may be a little too verbose, but you get the point. Also separating scripts to individual files could be useful. Separate script files would also make suggestion 2) be more easily achievable.

Questions

• Why doesn't the resolution numbering have 0,0 in the middle of the world? Currently it seems like the editing "stage" is limited in size..?
• Also, what does RGD stand for? I searched for an explanation but couldn't find anything that would make sense in this context. _________ Game Development, I'd guess, but I have no idea what the 'R' stands for.
• The project is closed source. But do you have some design documents you'd be willing to share? I'd be interested in getting to know more about how you're planning to move this project forward. Or is that something reserved for donators? (I am considering donating anyway).

I'm pretty sure I've also had other thoughts and questions about the project but I can't seem to recall them at the moment. I'll leave those for later discussion.

Hello! First of all, thanks for sharing your thoughts!
Sharing your thoughts, to say the least. It seems that you've actually invested some time and effort in this, which is really appreciated!

To be a little personal for a moment: I am also glad to see you again. I am happy that you are one of the users to tinker around . (Not to be arrogant, but you are the only one for now)
What I most value about you is actually that you are a lot like me. You have a creative and inventing mind. (Maybe this is why we are responding to each other at the moment, and nobody else is here?)
This kind of minds save the world

There is absolutely no reason why not thinking aloud. Your opinion is probably in top 5 most respected opinions I want to hear and I intend to announce this project in at least 3 (big) communities that would be interested in it.
Here I have to correct you - ORX is not new. It existed almost simultaneously with gE!
I also thought it's new, perhaps because I haven't heard of it, but Iarwain (the guy responsible for it) said ORX started about the same year as gE.

Original GE source isn't relevant to the year we live in now
so I don't think it is sad at all that it was abandoned.
It is like abandoning your bad memories, that's good isn't it?

Now let's digest your thoughts / ideas / suggestions.

1. I actually haven't thought of this. I am someone who always thinks too much and this..
I know reading through a project isn't easy, but never thought of how to improve it in my editor. Let's discuss this further when I reach that point, as scheduled.

2. Tabs for Script Editor
I already had made plans for the script editor, as it is one of the next phases of development.
There could be tabs, but I decided to use something a bit different yet quite similar. That would be a list view. It mainly differs in the position of "tabs" and that it takes less space. Other than that I don't think it differs. It will allow users to modify multiple scripts with a single click and then save all edits at once.

3. Advanced search functionality
What you essentially consider as a problem is actually what "reformatting" solves by itself.
No need for manual searching, the scripting engine can detect the need for reformatting and ask the user whether to perform reformatting.

4. Support for external code editors
This is the only thing I have to not agree on
I know that you aren't familiar with this, but I actually have (almost) completed an entire C-IDE project.
I can make Game-Editor2 integrated Script Editor more functional than generic code editors.
While it makes sense (and is very easy to implement) that user has a choice of selecting his own code editor,
it wouldn't have semantic highlighting and all the gE-specific tools that may be needed. It's just better that if user needs a feature - I implement it.
To be honest, if this is something that many still need for some reason, I'll do it anyway. It's as simple as adding a gfilemonitor to track for changes in a file and reload it in editor.
I don't agree on relying on external dependencies and the thought that integrated IDE may not be sufficient.

5. I wanted to contact skydereign, because he is probably the only one who could help me in one specific aspect.
It is something that I don't want to invest time in and that is - reading to .ged files. They are obviously binary, but also encoded. I need to be able to encode it and read it in order to make the editor backward-compatible, so that everyone can re-export their games, taking advantage of the improved performance, fixed bugs and added features.
Evidently, we think the same, because I already planned to modulize the export units. There is surely going to be an .INI file (textual) for configuration (actor creation and configuration), multiple files for each global code and a file describing events on per-actor basis. I was thinking to let users load each unit individually or all at once by virtue of a .ged2 project file, describing what should be loaded.
This will also greatly improve loading time and maintenance.

And now responding to your questions.
1. Why doesn't the resolution numbering have 0,0 in the middle of the world? Currently it seems like the editing "stage" is limited in size..?
Don't worry about that, the alpha version is limited to "a number of resolutions". Actually, game-editor is also limited, even though it looks infinite.
It is limited on size, not resolutions though, so it may end when the resolution is not displayed whole, which may not be what we want. I decided to limit based on a number of resolutions, which is slightly better in the context of game creation. I currently initiated phase 2 of the project, which is the beta version. I am able to alter this behavior if I find a better alternative.

2. Also, what does RGD stand for? I searched for an explanation but couldn't find anything that would make sense in this context. _________ Game Development, I'd guess, but I have no idea what the 'R' stands for.
Well, it's a new concept. I thought I mentioned it, but it turned out to be a deja-vu. Check "RAD Editor" and you'll see what this is about, G replaces Application with "Game"

3. The project is closed source. But do you have some design documents you'd be willing to share? I'd be interested in getting to know more about how you're planning to move this project forward. Or is that something reserved for donators? (I am considering donating anyway).
I believe I've said anything in this regard in the post
Also, I have no particular issue with sending you the very first alpha release for tests, I just don't think it is optimal, because as you can see from the post, I'm ending up rewriting it anyway, to a beta release (which is what happens now). If I do, there is a high chance that you comment on things already included in my to-do-list and then, when the beta gets released, we will have to do it again.
Other than that, It's fine to me. Have you explored the #Game-Editor2 channel on ORX? It's full of videos showcasing every feature that I implement in real time.

I don't see any particular problem in regards to the development, but I would hate if someone is dissatisfied with it, so opinion is also very important.
I choose game-editor to base the new editor upon, because it is the easiest engine to make games with. And yes, I did try every engine that serves as an alternative and yes I've observed what others think about available game engines. I became who I am, thanks to game-editor, I'd like to be the one who improves it. Marketing is really my business and I have no worry about it. I'll slowly make it known. I just want it all coming from game-editor.com since it's where it derives from and I want this to be clear even though I am not sure if Iarwain likes that it derives from here (probably not).

I always had a feeling that you, bat78, were the one to rebuild gameEditor into a modern game engine! I am glad to see that the gameEditor project may have a second life.

I’ve had a little look at the videos you put on discord, it looks like you have already been overhauling the interface! I see you have sort of got rid of the control panel? How will adding events look like?
My initial reaction to the new interface overall is that it certainly looks more clean and intuitive, with fewer drop down menus and things.
You want to implement backwards compatibility? That’s quite ambitious, the latest version of Godot doesn’t even have backwards compatibility with Godot 2 and before, I assume Godot 3 isn't built
from the ground up.

Hello Turon, good to see you.
I've already noticed that either your logic, intuition or both work very well for you.

I don't think that backward-compatibility is going to be hard to achieve at all.
It is a matter of decrypting/decompressing a .GED project file and reading through its binary structure. It won't be further complicated, because it already shares gE's features and interaction mechanisms.
I'll simply do it If skydereign or makslane agrees to participate. Otherwise, I don't have a strong reason to invest time in reading through game-editor sources. It is generally a better workflow to simply re-write your game. I'd advice everyone to re-write their games in game-editor2, taking advantage of all the improvements, regardless of whether there is or isn't a backward compatibility.

What you have seen in Discord is just pre-alpha snapshots, remember this
I just initiated this project. Everything is mostly the same, perhaps with the exception of the actor control being somewhat a revamped version of the game-editor 1.4.2 one:


This model is a lot better than a floating non-context window menu.
The only potential issue is that because there isn't treeview folding yet (section folding) and because there are obviously more settings, it may require that the user scrolls to access events, which are located at the bottom of the control actor pane. I actually thought of implementing a 1:1 copy of original game-editor actor control as well, just for the old habits and faster use of basic features.
I am still considering it, but there will be section folding or/and dockable dnd sections either way.

Adding animations and events is just like it is in game-editor original. As I said, it is going to resemble game-editor in every aspect, just greatly modernized and improved.
(By the way game-editor 1.4.2 interface appears to be based on wxWidgets, which tries to use as many native widgets as possible. makslane really evidently, I mean REALLY must like to use custom widgets for some reason)

Game-Editor deserves a second chance and it got it. Now I am re-writing the alpha version to a public beta (reasoning being mostly, but not limited to the improvement of performance and code structure).

Added link to ko-fi (https://ko-fi.com/gameeditor2) for those of you, who don't find Patreon for suitable.
Of course, don't feel obliged to donate, I know that this is a pretty small community and it's nearly impossible to find donators
Everyone have equal rights. Actually, I even think game-editor users must be more privileged.

I'll soon announce it in other communities and social media. Sadly that's what I can't seem to find time for as I would be preferring to be 100% focused on development only.
(that's a hint, if someone wants to do it, you should contact me on Discord, we can discuss on what needs to be done)

Everyone can provide support in many ways.

bat78 wrote:Here I have to correct you - ORX is not new. It existed almost simultaneously with gE!
I also thought it's new, perhaps because I haven't heard of it, but Iarwain (the guy responsible for it) said ORX started about the same year as gE.

Oh, I see. I was lead astray by the Wikipedia page of the engine, I thought the stable release date meant the first stable release, not the latest one.

bat78 wrote:Original GE source isn't relevant to the year we live in now
so I don't think it is sad at all that it was abandoned.
It is like abandoning your bad memories, that's good isn't it?

Well said.

bat78 wrote:1. I actually haven't thought of this. I am someone who always thinks too much and this..
I know reading through a project isn't easy, but never thought of how to improve it in my editor. Let's discuss this further when I reach that point, as scheduled.

Ok. I really think this is important, so I'll be glad to discuss it further when it's time to consider such things. There's multiple ways to address the issue, we'll try our best to dig up the most optimal solution.

bat78 wrote:3. Advanced search functionality
What you essentially consider as a problem is actually what "reformatting" solves by itself.
No need for manual searching, the scripting engine can detect the need for reformatting and ask the user whether to perform reformatting.

I think you may have misunderstood what I was talking about. Or then we apply different meanings to the word "reformatting". What I meant was having a tool for inspecting what scripts are dependent on / use a certain variable / function. Kinda like how in old GE if you try to remove a variable that was defined via the GUI the editor gives you a list of scripts that will break if the variable is removed. I think having this kind of listing can be quite useful for understanding how things relate to each other and what events can alter the value of a variable. It would be great if the list could then also be used to jump to any of the scripts, but that's just functional sugar.

bat78 wrote:4. Support for external code editors
---
I can make Game-Editor2 integrated Script Editor more functional than generic code editors.
While it makes sense (and is very easy to implement) that user has a choice of selecting his own code editor,
it wouldn't have semantic highlighting and all the gE-specific tools that may be needed. It's just better that if user needs a feature - I implement it.

I see. I understand that there's major benefits to be gained by having a custom editor. My only fear is how much work will it be? A fully featured source code editor is a pretty large and complex thing to implement. Not that I didn't believe you could do it - I'm 100% sure you have what it takes to program that. I'm just thinking about the prioritization of development resources (mainly time). When there's only 1 person working on a project, proper prioritization becomes very important - developing one feature is inevitably going to delay the implementation of other features. (As you probably know, I've personally failed at this countless times, and quite miserably. ) Of course, I have no doubt in my mind about you having thought about all this already though. It's just that I don't have the data about your estimations on the workload of implementing specific features.

bat78 wrote:5. I wanted to contact skydereign, because he is probably the only one who could help me in one specific aspect.
It is something that I don't want to invest time in and that is - reading to .ged files. They are obviously binary, but also encoded. I need to be able to encode it and read it in order to make the editor backward-compatible, so that everyone can re-export their games, taking advantage of the improved performance, fixed bugs and added features.

You're going for full backwards compatibility? That's no easy feat. But an admirable one nonetheless. Partial backwards compatibility where all the most important parts work the same but some minor details may behave differently could be a little easier to achieve.

I actually once tried to find out how to read a .ged file. I think I did find out what encoding was used, but iirc it was some obscure, very much non-standard encoding with little to no documentation available. I may remember wrong though. But I gave up trying as I had trouble even finding the part of GE source where a project file is decoded and loaded.

bat78 wrote:Actually, game-editor is also limited, even though it looks infinite.
It is limited on size, not resolutions though, so it may end when the resolution is not displayed whole, which may not be what we want. I decided to limit based on a number of resolutions, which is slightly better in the context of game creation.

Isn't GE's stage size limited by variable min and max bounds? That's what I've always thought. That's pretty close to infinity in practice. (I actually did some testing now and to my surprise, I got some weird results.. I set the view's coordinates to large values and attempted to put an actor on screen by setting it's coordinates, but with mixed results.)

bat78 wrote:3. The project is closed source. But do you have some design documents you'd be willing to share? I'd be interested in getting to know more about how you're planning to move this project forward. Or is that something reserved for donators? (I am considering donating anyway).
I believe I've said anything in this regard in the post

Well, yes, the original post outlines the big picture of your intentions with the project. But I was interested in a little more detailed documentations, regarding the structure of the code and program architecture. My software development studies have contained a lot of documentation and because of that I'm interested in seeing how and to what extent people design their projects. Of course, detailed design documentation is less important when developing alone, as it is largely a tool of communication for software development teams. Yes, I've explored the #Game-Editor2 channel and it's been interesting. I hope to see more updates there as well.

lcl wrote:Oh, I see. I was lead astray by the Wikipedia page of the engine, I thought the stable release date meant the first stable release, not the latest one.

It's formally defined as "Developed since 2007, and with roots going back to 2002" whatever that means

lcl wrote:Ok. I really think this is important, so I'll be glad to discuss it further when it's time to consider such things. There's multiple ways to address the issue, we'll try our best to dig up the most optimal solution.

Ah yes, very important. I'm interested to hear your point of view on the matter. We can perhaps discuss it with Romain Killian (a.k.a Iarwain) the three of us or something. That guy
is the real deal in the world of game development

lcl wrote:I think you may have misunderstood what I was talking about. Or then we apply different meanings to the word "reformatting". What I meant was having a tool for inspecting what scripts are dependent on / use a certain variable / function. Kinda like how in old GE if you try to remove a variable that was defined via the GUI the editor gives you a list of scripts that will break if the variable is removed. I think having this kind of listing can be quite useful for understanding how things relate to each other and what events can alter the value of a variable. It would be great if the list could then also be used to jump to any of the scripts, but that's just functional sugar.

I still hold on to what I have said initially - if a reformatting feature is implemented:
1. It will ask the user whether to perform reformatting if for instance a variable identifier has been changed and there are multiple occurrences of it across the scripts.
2. Upon reformatting, those occurrences will automatically be replaced with the changed variable identifier.
We'll further discuss implementation details in regards to the interpreter and the scripting engine that I will write.

lcl wrote:I see. I understand that there's major benefits to be gained by having a custom editor. My only fear is how much work will it be? A fully featured source code editor is a pretty large and complex thing to implement. Not that I didn't believe you could do it - I'm 100% sure you have what it takes to program that. I'm just thinking about the prioritization of development resources (mainly time). When there's only 1 person working on a project, proper prioritization becomes very important - developing one feature is inevitably going to delay the implementation of other features. (As you probably know, I've personally failed at this countless times, and quite miserably. Of course, I have no doubt in my mind about you having thought about all this already though. It's just that I don't have the data about your estimations on the workload of implementing specific features.

Don't worry about that
Surely you have no way of knowing how hard will be the implementation of a particular feature, so worrying is normal.
A good custom script editor in my working environment would be one of the easiest features to implement.

lcl wrote:You're going for full backwards compatibility? That's no easy feat. But an admirable one nonetheless. Partial backwards compatibility where all the most important parts work the same but some minor details may behave differently could be a little easier to achieve.

Hmm is it? From my standing point, it doesn't seem to be that hard.

lcl wrote:I actually once tried to find out how to read a .ged file. I think I did find out what encoding was used, but iirc it was some obscure, very much non-standard encoding with little to no documentation available. I may remember wrong though. But I gave up trying as I had trouble even finding the part of GE source where a project file is decoded and loaded.

We could perhaps reverse engineer it, but then it wouldn't be a worthy time investment. As I said, if skydereign or makslane wants to help achieving backward compatibility in my editor, I'd just need them to tell me how to decompress and/or decrypt .GED files and a header/data segment description would also help a lot. If it is encrypted, the encryption key should be stored somewhere too.
I don't think it is though, because I don't see a reason to.

lcl wrote:Isn't GE's stage size limited by variable min and max bounds? That's what I've always thought. That's pretty close to infinity in practice. (I actually did some testing now and to my surprise, I got some weird results.. I set the view's coordinates to large values and attempted to put an actor on screen by setting it's coordinates, but with mixed results.)

If you are thinking about "x" and "y" variables - yes and no.
Of course, space should be limited by a data type, unless it is created/destroyed dynamically in chunks stored in buffer memory, which isn't what's happening here.
The so-called editor map space (I call it editor world) represents physical space and the "x" and "y" variables represent logical position. Those variables serve as a reference point in the game world and not the editor world. You would see different and potentially non-mutually-compliant results when testing bounds by virtue of double overflow or navigating in the editor to its limits.
You can try the following: Create a simple actor and place it at the center. Create it infinite on the horizontal, maximum zoom out and start scrolling left or right. You'll soon run out of space and the (x,y) label will rollback, indicating that the world wrapped to the other boundary and you are moving in the opposite direction. Also, you may experience weird grids and resolution drawings in different zoom levels. The value you've seen last represented by the (x,y) label is the maximum/minimum of the physical space. The value I registered (and forgot) was not close at all to a 32 bit type maxima, so it is either limited on purpose or it is because the editor map space should actually multiply when zooming-in and it shouldn't overflow the data type representing it.

Finally, to wrap it up I'd say that it is limited on the developer-side by the physical world (editor map) space (which is represented by an internal data type) and on the running game side by the "x" and "y" variables representing actor position in the game world.

lcl wrote:Well, yes, the original post outlines the big picture of your intentions with the project. But I was interested in a little more detailed documentations, regarding the structure of the code and program architecture. My software development studies have contained a lot of documentation and because of that I'm interested in seeing how and to what extent people design their projects. Of course, detailed design documentation is less important when developing alone, as it is largely a tool of communication for software development teams. Yes, I've explored the #Game-Editor2 channel and it's been interesting. I hope to see more updates there as well.

You are interested in my code or do I not understand correctly? Unfortunately, the project is closed source so I cannot do much
As for the program architecture, I am pretty sure I didn't miss describing it already, but hey! Why not do it again?

I am using ORX and the most recent GTK+ windows toolchain. The editor-side rendering is done using Cairo, which is part of GTK+. I'm also using plenty of my own APIs:
- orxAPI for better interfacing the editor and ORX engine
- Gtk Style API for real-time CSS styling
- FILEIO for "engine_settings.ini", a modular settings interface
- GtkSprite Sprite management and animation
- GtkGameWorld, GtkGameActor, GtkRotaryKnob - custom widgets
- GAllocator - custom slice allocator with support for grouped allocations, encryption, locking, garbage collection and more
- TerminalIO custom feature-rich debugger console
- CNP (to be used in the future, a networking protocol I have created before)
The alpha version you are familiar with has `10372` lines of code according to a code statistics plug-in that I do not trust at all.
The new beta version seems to have 41842 lines of code - that's why I don't trust it

Also how about testing the upcoming beta? As a respected GE member that has helped me with feedback I can let you do that regardless of whether you donate or not.
But I allow such an exception only exclusively for important contributors such as Iarwain, just for everybody to know.
The alpha had 10 known issues, which were not critical (of course none of them were crashes), with the only exception being the removed zoom optimization.
All these issues are faced in the beta along with cleaner code, more features, and a completely different rendering mechanism.

One thing that I always struggled with when using gE and one of the reasons why I ultimately abandoned it, after creating loads of games with it, was the inability to easily group actors.

A simple example would be this.

I have an enemy. But the actor is just a rectangle shape, so that collisions are cleaner and things don't get stuck. When creating the enemy actor, I thus spawn also another actor, which would be the actual visible sprite. I don't want to make this actor the child of the rectangle, because the child inherits properties that I don't want it to inherit.

Obviously, there are multiple enemies in the game, so I have clones of each.

The problem arises when I interact with the rectangle and decide to destroy it. The way to destroy the rectangle would be to use DestroyCollider(). However, there is no in-built mechanism to access the sprite too.

I eventually found a way to use actor variables and store actor ids in the sprites, so that I can later access them, but this was very awkward.

In many other game engines this problem is sidestepped by having a collision shape be simply a property of an actor and not have to use a separate actor. So, I don't know whether this would be a challenge for gE2.

Another question is - how proven is the ORX engine? I have never heard of it before, and I have been following game engines for years. Its Wikipedia page is not very informative.

Hello!
Your name looks so familiar.

Short answer - not at all.

ORX really uses the best collision-detection and joint mechanics available to this day. It uses box2D in conjunction with other technologies.
Also, I believe it has the power to let developers choose a collision algorithm, being a bounding box-based (square) or a multipolygon collision. Additionally, one can create a very good collision-detection using getactor() in Game-Editor. I can maybe upload a demo to showcase it. It can then be reused by others. I actually decided to add "Templates" feature to game-editor that allows you to choose generated presets of different game objects separated into categories. For example:

Platformer
-Player
-Spring
-Collectable
-Hazzard
RPG
-Player
-Dialogbox
-inventory
Shooter
-bullet
...

You'll be able to one-click create a working player that you can edit on your taste. This allows for quick prototyping and reflecting your ideas quickly and directly onto the surface.
We'll see how exactly I'll implement collision management. This isn't something to be concerned at this point.

Regarding your second question:
First I would like to ask you to simply edit your post rather than create a small follow-up one, if it isn't a problem, otherwisem I'll have to ask mod to do it

That question was actually asked just now, by another user, so I'll just copy-paste my response:
ORX isn't known on purpose. The guy who created it never had any intentions to make a widely known product that he can make money from. It's free and he is happy with a small, selective, but powerful community.
About how potent it is, as you can read from here: https://orx-project.org/
It is as capable as any modern kit (if not more).
And even though it didn't have an editor (such projects were discountinued), there are in fact, very nice games made with it: https://orx-project.org/showcase/
Also it doesn't have to be proven anyway. I learned about it, read about it, tested it and discussed it with the owner. I concluded that it will be the perfect underlying engine (much like SDL1, Kyra, etc is for Game-Editor)
It supports developing under Android, performance is great and it is really rich in features. All it needs is a good editor and I decided to make one, based exclusively on Game-Editor.

Allow me to provide general feedback from my personal point of view, explaining why gE is so special and why I was incredibly productive with it (and became less productive once I stopped using it).

Pros.

1. Short path between starting and seeing results on screen

There are two types of game frameworks: with a GUI and without one.

Game frameworks without a GUI tend to be relatively easy to pick up and use, but they require extensive setup to begin using them and tend to have more complicated ways to add simple things, like actors, asset, animations. You need to declare everything, copy and paste a lot of things, etc.

Game frameworks with GUI tend to be with GUI not to provide simplicity, but to accommodate an extremely complex setup. I am specifically thinking of Godot here. If Godot would have no GUI, setting it up with code would be a nightmare.

gE is unique, because it is a combination of a minimalist GUI and a set of predefined functions. The GUI takes care of things that would otherwise be pretty tedious, like declaring new events, uploading assets and configuring animations.

Because of that, gE offered the shortest route between your urge to put something together and actually seeing results on the screen. In just several minutes I could create an actor, assign a bunch of simple actions and get the sprite animation going. I didn't test too many game frameworks, but adding sprite animation in Love2D requires a special plugin, which is bizarre, and adding spite animation in Godot is a joke - at least it was a joke in Godot 2. Minutes and minutes of fiddling around just to get a simple thing done and no easy way to speed it up or down without recalculating the delays between the frames. The way gE handled it was intuitive.

I personally stopped using menus for events and ended up immediately going to Script Editor, because almost always I would need to add custom code, and also events from menus would be more difficult to track. By using the Script Editor I was able to more effectively group events. I would do a lot of setup from the Create Actor call for instance. And if I would want to change something, I don't need to click around, I just need to open the script editor and modify things there.

This is a roundabout way of saying that I think that menu actions lead to worse workflow and I personally think that when you create an event, it should always lead to the script editor - and this is just my opinion. Perhaps this would be less of a problem if there is a list of events like lcl suggests.

2. Unique collision mapping

gE also has a feature that I have since discovered to be absolutely unique: non-transparent pixels of an image would automatically be considered as something that can be collided with. This allowed me to generate an image of a maze with transparent background, add it to the game and immediately have the player actor collide with its walls. I thought this was something that should work in every game engine, but the way collision is implemented in most other engines I tried, you need to actually draw the collision shape, it won't be deduced automatically. While I understand the option of drawing a collision shape, that automatic method of gE allowed me to create maze games that are impossible with any other tool that I've tried. (Unless you program it in yourself, I guess)

It also considerably speeds up game development, since in the vast majority of cases you want a simple non-dynamic collision shape. I would sometimes use an invisible actor shaped as a rectangle or whatever is appropriate against the sprite if I needed more control. For a lot of 2D games that's all you need. Switching the invisible actor's animations also allows you to dynamically control your collision shape if that's what you need. Yes, maybe in some rare cases people need even more control, but the ensuing complexity it's definitely not worth, imo.

Unfortunately, from what I can see, ORX has a pretty complicated approach and this kind of functionality will be impossible.

3. Easy to use API

Many modern engines, including ORX, don't provide too many simple pre-built functions. I see that you need to write a lot just to get simple things done. I was looking at some collision tutorials. And, oh boy. The verbosity is beyond my comfort level. This is definitely no longer quick. You need to pass on loads of parameters, handlers. I honestly find it difficult to understand what's going on - and these are basic tutorials!

This is the code to determine if the collision has occured, for example. In gE it was just a single line of code, CollisionFree.

Code: Select all

orxSTATUS orxFASTCALL PhysicsEventHandler(const orxEVENT *_pstEvent)
{
   if (_pstEvent->eID == orxPHYSICS_EVENT_CONTACT_ADD) {
      orxPHYSICS_EVENT_PAYLOAD *pstPayload;
      pstPayload = (orxPHYSICS_EVENT_PAYLOAD *)_pstEvent->pstPayload;
   }
   return orxSTATUS_SUCCESS;
 
}

What is this?

I mean, of course I sort of understand what's going on. Sort of. But this is something for an advanced user. I do need a bit of advanced scripting, but not full on coding. I would rather this was hidden from me and I could use something like ifColliding(object, object).

Instead, they have a wall of text for that check. See that tutorial here.

4. A good balance of simplicity vs complexity

Simplicity is usually a tradeoff on the amount of options. I felt that gE had the right amount of limitations for a 2D game engine: it never tired to be anything else, which might have made some weird things more difficult, but made working with 2D sprites incredibly efficient and easy.

Cons.

In no particular order I will list things that I personally missed in gE. I understand that the new engine is likely to not have these problems, but I'm listing these anyway, just in case this feedback would be useful in ways I cannot predict now.

The list is longer than the list of advantages, but it were the advantages that mattered to me. I used gE for almost 10 years. And would have been using it for 10 more if it was maintained. Especially if a couple of small things were fixed.

1. Bigger games were very difficult to pull off.

This is where my experience with gE is limited, since my early experiences with making your standard platformer, with levels and lots of enemies and collectible items (I wanted to make something like Commander Keen) proved to be a failure due to technical reasons: I did not use areas and gE began lagging as my level grew. I was given advice to use areas, but as soon as I started doing that, this functionality proved to be unreliable: I had random actors not get loaded randomly, other actors not destroyed, etc.

I never got into making levels or a level editor. I understand that this is possible with gE. Maybe one can use an XML or a level file. In one of the games I did end up using the "load level" functionality, because there was no quick way to reset the state of the game. And this level loading was a bit rough around the edges: the screen blinks when you reload the level. And source-wise it's messy, if I remember correctly you need two separate projects. I remember wanting to not go through that again.

2. Physics engine was unreliable.

To the point that I stopped using it altogether and relied on CollisionFree and writing my own physics engine. This is actually possible for simple platformers, but of course an engine like Box2D allows you to throw things and all that.

3. Grouping actors was difficult.

I wrote about this in this thread, so won't go into details. I found a way to do it, by using custom actor variables and setting these to the same number and the actor clonenumber when creating the actor I considered the main in the group (usually the colliding object).

4. Text editor was very difficult to work with.

5. There was no rotation.

It's interesting, but this was really the only important dimension that was missing from actor manipulation. The inability to rotate an actor was pretty limiting, especially for top down games. Adding just that dimension to gE would have made it a billion times more useful.

6. Manipulating text was difficult.

Later I actually found relatively easy ways to do it, but it took me a long time to understand how to manipulate text in C.

Text manipulation is generally difficult in desktop games, especially for those of us who are used to making JavaScript games, where thx to HTML manipulating text is a piece of cake. Even when I worked in Phaser, which is really sophisticated and a game engine I would recommend, working with canvas and fonts was a nightmare.

Having said that, let me give you a huge pro: adding custom fonts was really easy. The font tool had some problems, but they were GUI problems, like you had to essentially add a new font instance, when all you wanted was to change it's color or something like that. Like, there was no way to just update your font settings. But other than that, it was a nice option to have and many game engines actually don't have it.

7. Sound on Linux was handled with an outdated OSS library.

8. gE actually had a very reachable coordinate limit.

In one of my games you can actually run into this limit relatively quickly (https://louigiverona.com/?page=projects ... mes#qtower). The game gives you an option of a "fidget mode", where you just jump down the platforms and collect items. It's very calming. But several minutes later there will be no more platforms, since the game runs out of coordinates, probably because they are integers or something. But you can keep on falling forever, though.

9. No ability to draw.

In one of my games your goal is to clean walls. I had to use small particles for "dirt". This made some levels pretty slow due to the amount of actors on screen. I would have preferred to intead draw stains and then be able to erase them. I do see that many engines allow you to actually draw, like on a canvas. Not a big deal, and you can also make an argument that this is exactly the kind og limitation that provides for the simplicity of the engine. But if there was a canvas object that you could manipulate, that would be interesting. It would also allow actors to leave traces on screen and all that.

10. This is a big one: no scaling.

When I was finalizing my gE games in 2019, I spent the last year upscaling my games, since they looked tiny on modern monitors. I actually had to quadruple one game, which involved not only upscaling the graphics, but also going through the source code and multiplying all coordinates by 4. Thankfully, it proved easier than I thought, albeit tedious, and I did not run into any problems. But scaling is key for a modern game engine.

11. A small one, but screwed me in one game: no ability to seed the rand function. That means you cannot utilize it to re-create random experiences. I guess I could have used the Doom method: they had a fixed array of numbers that they used for an RNG call. Didn't think of it back then. But, either way, this has to be an option.

12. No way to access (some?) actor variables from Global funcions.

I don't remember exactly what the limitation was, but it was pretty serious and stood in the way of a lot of things. I think you could not call an actor variable from a Global function or something like that. People explained it to me in terms of function scopes and it made sense from that perspective, but made little sense when you were using it and expected to be able to call any actor and any variable. There was a limited workaround.

-----------------

I think that's about it. I'll chime in here if I remember something else. Obviously, there were both good and bad things that I am not thinking of right now, but the gist of it is here.

I would say this - I would be very excited for gE2 that has the same workflow, but more capabilities. That might allow me to make more games again. I mean, I would use gE for more than games, I used it to build models, quick ideas. I have been looking at NetLogo for some of these, but for many-many years gE was my go-to tool for almost everything. Would love to have gE2.

Hello!

Thank you for your feedback. I'll try to respond briefly this time as nobody likes reading text and people tend to just skip on potentially important bits.
To be honest, what I hoped for is a commentary on the very next thing I'm working on - Actor Control. I guess I'll just be doing it on my own, the way it is in the Alpha with the improvements I decide.

By the way, I just submitted after an hour of writing and the forum just threw me off with a log-in prompt again and I lost everything I've written so now I'm mad. Let's not use forums from now on I now hate it so much.

This is a roundabout way of saying that I think that menu actions lead to worse workflow and I personally think that when you create an event, it should always lead to the script editor - and this is just my opinion. Perhaps this would be less of a problem if there is a list of events like lcl suggests.

Menus or "GUI Scripting" are meant to assist people with no skill in language-based programming. That is usually the young people, but not always.
If my editor is targeted only towards the advanced user base and is only for professional use, it just makes it less valuable in general.
However, since your feedback made me think more, I just came up with the idea to schedule an option to open Script Editor immediately after selecting the event - "Disable GUI Programming"

Unfortunately, from what I can see, ORX has a pretty complicated approach and this kind of functionality will be impossible.

But you don't have to worry about that, don't you? I am the only one who is and who will work on the editor and its underlying libraries.

3. Easy to use API
...

I agree, but I don't understand why do we have to compare Game-Editor with ORX. Game-Editor is a RAD (RGD more appropriately) engine for game development and ORX is a framework/library or "editorless game engine". Nobody has to care about it too.
Everything will be implemented just as it is in Game-Editor, as I said many times. I'll be writing a custom C interpreter for the language-based scripting part. The pre-defined function will be the same, except that there will be a "more" button with at least twice as many built-in functions. That's my approach to maintain the look and feel of the old gE. You can see it with Game Options and Preferences already.

1. Bigger games were very difficult to pull off.

Ah, that would be one of the smaller reasons for me to start working on gE2.
I devoted so much time in a game that is quite literally the biggest one to be created in Game-Editor and oh boy..
I had to hack around engine bugs in every corner and ultimately reached the point of the engine being completely incapable to handle it.

One of the few things I might as well NOT implement in the new editor got to be the way Game-Editor handles levels. Aside from the fact that Game-Editor isn't performant per se, the
The generic approach would be to either use `LoadGame()` which is slow or use "Activation Regions", which is hard to "read" (maintain).
Since the "editor map" or what I call "editor world" is implemented via a widget, I can easily implement "Add Map" which opens a new editor world in the same game, and then it gets executed upon
`loadMap()`. Similarly, a "Add Layer" can be implemented with the difference that both worlds will be executed simultaneously. But due to prioritization, I may not get to add it just immediately.

3. Grouping actors was difficult.

I think I should add an overlay icon on cloned actors that indicates that those are clones and so you'll be able to quickly determine which is the "source" actor and which are clones. The problem is that conceptually if you create a clone, all actors are considered "clones" at this point. There are multiple ways "Actor groups" can be utilized within Game-Editor. One that probably feels more intuitive is to select a toplevel actor and have each other parented by it so that you can easily access all actors in the family recursively by virtue of the "parent" actor instance variable. It isn't perfect, but as you have found out there are other alternatives as well. I think I should add a concept for "Actor Groups" though.

5. There was no rotation.
...

What about mirroring? In the slightest, It would have made platformer player movement much easier to achieve.

8. gE actually had a very reachable coordinate limit.
...

The problem is that gE does not define well its space limit, which leads to unexpected behavior in games.
That's why initially I restricted world space by a number of resolutions, but this is altered in the new upcoming beta.
What would potentially fix this issue is the aforementioned map loading concept.
`createMap()` to create a new editor map and `loadMap()` to load it immediately and `addLayer()` to create a new editor map and execute it simultaneously.
That way we can practically have infinite space, infinite levels, without waiting or performance issues, without activation regions complexity and all within a single executable.

9. No ability to draw.
...

Here you got me a little confused. Aren't you listing all flaws in the game-editor we know?
Game-Editor has got canvas and drawing functions. This is precisely added to support drawing particles.

Meanwhile, everyone is asking what will be challenging for me to implement. The answer is - probably canvas and drawing functions.
The underlying game engine (ORX) supports efficient means to add particles, FX and whatnot, so the use of canvas is now vague. I do want to keep them at least for debugging purposes, but the problem is that this would be no longer efficient - ORX uses 3D renderers to provide hardware-accelerated rendering.
Now, setting a single pixel is possible, but terribly inefficient as you'd need to retrieve the render target texture from the GPU memory after all the draw calls were made, sync the part you want to change to CPU memory and push it back afterward
usually, as with all 3D graphics card, you want to do as little as possible of this kind of drawing as it stalls the entire rendering pipeline.

10. This is a big one: no scaling.

When I was finalizing my gE games in 2019, I spent the last year upscaling my games, since they looked tiny on modern monitors. I actually had to quadruple one game, which involved not only upscaling the graphics, but also going through the source code and multiplying all coordinates by 4. Thankfully, it proved easier than I thought, albeit tedious, and I did not run into any problems. But scaling is key for a modern game engine.

By the way, have you used LcL's "Resolutionary" API?

12. No way to access (some?) actor variables from Global funcions.
...

That is common gE misbehavior. You can only "read" to actor variables, but not modify them through the "Global Code".
A workaround this is to use an Actor pointer as returned by `getclone()` for example or weirdly use a comment containing the actor's name. Either way, this is no longer relevant.

With that being said, thank you again for your dedication!

I just don't have any special wants for Actor Control. I added bits about font editing, for example. But in general, I'm happy with it. I do like lcl's suggestion regarding listing events. But I would love to keep Actor Control generally as it is.

I just came up with the idea to schedule an option to open Script Editor immediately after selecting the event - "Disable GUI Programming"

No, no. You are right that GUI programming should stay. I just explained my workflow. I don't think I need that option. I have no problem selecting Script Editor.

But you don't have to worry about that, don't you? I am the only one who is and who will work on the editor and its underlying libraries.

I understand. But I wanted to say what was important to me in gE and what doesn't work for me in other frameworks. Love2D is also a GUIless framework, as is Phaser, but they are much easier to use.

I think I should add an overlay icon on cloned actors that indicates that those are clones and so you'll be able to quickly determine which is the "source" actor and which are clones. The problem is that conceptually if you create a clone, all actors are considered "clones" at this point.

That's not what I am talking about. I am talking about a concept of groups. That gE does not know which actors are connected, not that I don't know. (In my workflow, for instance, I never even put anything on screen, I create everything from code. So, it's not about an overlay at all).

The situation is this: I create an invisible collider actor. Then I create a visible non-colliding sprite with the same coordinate values. As far as I remember, making it a child was impossible due to either collision status of visibility status being inherited. So, it had to be a separate actor.

Then I would control the collider actor through its draw function, which would also control the visible sprite actor.

Now imagine I shoot an enemy. But a collision event only exposes the collider to the event. gE knows nothing about the sprite actor. And, therefore, what would happen is that the sprite just stops dead. But there is no way to delete it, because I have no way of accessing it. And because this is a clone and not a unique actor (you have many enemies on screen), you need a group_id of some sort. And this is the mechanism that I am asking for.

I managed to create a group_id myself using actor variables. But I would have preferred not to have to go to all that trouble and simply have access to a predefined actor variable "group id".

What about mirroring?

Good point. But you could at least fake it through adding an additional animation and it was not too difficult. With rotation you could not add 360 additional animations. So, mirroring had a quick workaround, but rotation did not.

Having said that, mirroring would be great, totally agreed.

game-Editor has got canvas and drawing functions. This is precisely added to support drawing particles.

My bad then. Never used it. My own oversight, then.

By the way, have you used LcL's "Resolutionary" API?

I know about it, but adding it to existing games felt much more complicated then simply altering the size calculations at this point. Either way, it's a workaround. I'd rather just have scaling by default. I am sure gE2 won't have that issue.

Oh, I was just speaking my mind aloud about the clone indicators, not that I didn't understand what you meant.
As I previously posted, the collision detection system is going to be better and more flexible and I am thinking to create a concept for "Actor Groups".

About the mirroring - it's not just mirroring a sprite (which is actually a pretty annoying process and requires one to lose focus).
Let's say you do it, okay, but then you will have to add another event on another key (or another clause in a script) to handle moving in the other direction.
Mirroring by virtue of a Control Control property, as it is in the alpha (videos for it in ORX Discord channel), will mirror the actor physically. So you'll only have to define the movement in one direction.