Super Duper Proposal Update

[XANOZOID]

Here's a mind dump of features I'm hoping can be brought into the program in some shape or form. Some things may exist, but from my first glimpse of Ogmo Editor I don't think they do.

Feature Requests

• Mask Editor and Mask Layer (not just that square layer thing)
  • I would really like to use the mask-layer thing for non-square shapes too. Like triangles, or circles, or rectangles, or half squares etc.
• Creating Map Layer Templates
  • Right now, this doesn't feel like a "project" based editor. It feels like a "single level stamp" editor - because we only create one level type and use it for everything - which isn't almost never what we intuitively want in a generic project-based editor
• Letting maps embed their own custom layers and change it up after creation
  • I like the idea of a template system, but maps/levels should have a concept of their composition embedded within them; it's just more natural to our thinking process I would imagine.
• Background or Image layer
  • Drag and drop images to the foreground or background of things . . .
  • Reposition, scale, tiled-x tile-y, and possibly enable the editor to have background types with required fields?
• Settings, but for the individual level/map
• Generic Shape Layer + Shape editor for entities ...?
  • I see this being useful for rapid prototyping and designing dynamic and flexible entity masks
• Component Tying (somehow) & Cross-Map component tying
  • By tying, I mean dragging a connection point from one component to another connection point
  • It could be a generic connection, or a typed-connection
  • By typed-connection, I mean that a door doesn't want its exit to be a random enemy..etc
• Multi-tiered Grid:
  • There's obviously a grid, but what about sub-grids, for instances such as splitting a level into multiple smaller levels that connect to eachother (based on a grid) like VVVV
• Views and View Boundary editor / Layer
• Item Dropping System
  • Allow components to have an option to accept other items be dropped into them
  • I see this being useful for RPG things like a chest and someone putting a specific sword in there
  • I would like it to be composable such that any item in there can be pulled back out and any editor-level properties on that element still exist . . .
  • I can also see it being useful for like, putting an item on an enemy ETC
• Text Layer
  • Aka, adding random text to places
  • Possibly enabling a level to render names of groups as text
  • Possibly adding fields to entities that gets added as a movable text component above them...

Advanced Feature Requests

• Frames Based Tween Layer
  • This is the best thing ever from Godot . . .
  • It would make cutscenes or level breaking, or moving platforms, or AI paths extremely flexible
  • It would also be awesome for allowing properties to have state-system and animatable
• Dialogue Layer / Editor?
• Integrated, very basic, pixel-based sprite editor
  • would prefer it to be feature-light weight
  • IE: colors, opacity, basic shapes + line, eraser, bucket, pixel size, frames, copy paste, and png export . . .
• Use HaxeUI over OpenFL/Kha/...
• Plugins :P

If you'd like to discuss over messages send me message over discord, or a group discord chat, whatever - I'd like to help where I can!

[XANOZOID]

Forgive me if some things are not accurate or completely wrong. I used Ogmo for the first time about 3 weeks ago so some things might be that way, or completely wrong. Which I'll fix immediately!

[TheSpydog]

Hey, thanks for the suggestions! A few questions/comments...

Mask Editor and Mask Layer (not just that square layer thing)

Not sure what you mean by this? What kind of masks?

Background or Image layer

Have you seen Decal Layers? They're intended for this use case. The documentation on them isn't super great at the moment though.

Settings, but for the individual level/map

You can already add Level Values to your project that you can set for each map. Is that what you mean?

Views and View Boundary editor / Layer

Huh, I thought this was already implemented but I can't seem to find it? OE2 had it... surprised it's not here as well.

• Item Dropping System

It's not as snazzy and tactile but you could use custom entity values for this. That's what I've done in the past -- just add a string or enum or whatever and set it per container. :)

• Integrated, very basic, pixel-based sprite editor

This is definitely out of the scope of the project. Aseprite or Piskel will probably serve your needs better than anything we could rig up, haha

• Use HaxeUI over OpenFL/Kha/...

We don't currently use OpenFL or Kha. It's all WebGL / jQuery / HTML5-y goodness. Unless I'm misunderstanding what you're saying?

[XANOZOID]

Not sure what you mean by this? What kind of masks?

Last time I used it, there was a layer editor that was literally just about placing down black boxes - not very useful past "one" shape.

Have you seen Decal Layers? They're intended for this use case. The documentation on them isn't super great at the moment though.

I have not, but I don't imagine they have some of the other suggestions I edited recently!

You can already add Level Values to your project that you can set for each map. Is that what you mean?

Awesome! Yeah I did not notice that, but I guess in my mind what you're suggesting is a "template" feature while I'm also thinking about the embedded level side of things

Huh, I thought this was already implemented but I can't seem to find it? OE2 had it... surprised it's not here as well.

All good, but a key thing here is that the whole "Boundaries" concept is also suppose to not just be for "defining" the bounds of a viewport, I'm also talking about boundaries in the sense that in old-tiled based game they had limits and constraints for where players could go. Think "Metroid" or "Megaman" where the view would follow predefined areas and all.

It's not as snazzy and tactile but you could use custom entity values for this. That's what I've done in the past -- just add a string or enum or whatever and set it per container. :)

A lot of my feature suggestions are going to have some analogous feature at some point, my idea was to enhance the features to improve the "pleasantness" of using the application as well as supporting a more flexible, composable, dynamic, and RAPID development. The drop system would be perfect, intuitive, and innovative for this!

Image editor

All good, it's only to improve the RAPID side of things - not a key feature haha

Use HaxeUI over OpenFL/Kha/...

I'm saying that the framework could be overhauled to support a more agnostic UI framework . . .

And just to emphasize a note:

I'd be willing to start/complete a fair bit of these on my own if they're not against the vision of the application. I just feel like there's a few nagging reasons, right now, for why Ogmo isn't going to be my first pick - just yet. I'm all about raising the bar to improve the application experience. If this was a API we were talking about I'd resist too much change, but for a level editor that is supposed to enhance and raise the bar for making games, that's what I'm going to aim for!

[XANOZOID]

Not sure what you mean by this? What kind of masks?

Looks like I was talking about the grid editor or something . . . I guess I don't understand the editor too much.

[raeleus]

I use an enum for item dropping. That works well. I don't like a lot of my game logic going into my level editor because that forces me, as the programmer, to conform to someone else's framework. I would prefer it to be a simple drop down menu, which we already have.

I would love having a shape editor. Some games work better with circles or other kind of geometry for physics and collisions.

[XANOZOID]

I'm not sure I understand the argument. The idea of being able to select an enum will persist, and having item dropping is strictly a visual, data-oriented feature. It would not remove any existing workflow or framework but improve the composability of the development process without enforcing a particular way to design their games. Instead, it would preferably be a more fluid and visual way to extend the existing functionality. It's only an upgrade.

No need to remove or neglect a feature if it improves usability without forcing someone to change their workflow.

Enums are too rigid and set in stone. Why not express it in terms of an entity, perhaps a strictly meta one with an icon, that uses an existing enum but furthermore allows you to force some fields like "rarity" or "color" or - just things that are dynamic but you don't want to empose on something else. Like I get that everyone can have enums on something like a "chest".

IE chest -> enum-item:Coins. Cool, we've just done what editors have been able to do since the early 1980's. But, chest items are more dynamic than coins. Chest items can be an enum with guns or coins or swords, and I wouldn't want to make a whole bunch of enums to express each type - and I certainly wouldn't want to associate the properties of the item on the chest itself. Plus, what if you wanted to later on refactor your level and pull the item out because it can exist on its own or inside of something? Tough break doing that for several different things.

I didn't think of these features for non-useful reasons after all...

[AustinEast]

Hey @XANOZOID 👋 I appreciate all the suggestions/comments, but I feel like the scope of this issue is a little too broad to have a good discussion on the different topics. Would you mind splitting this up into individual issues so we can discuss/track them individually a little easier? There are also issues open for some of the features you've suggested, like Text Layers, that you are free to discuss/contribute to :)