-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Super Duper Proposal Update #107
Comments
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! |
Hey, thanks for the suggestions! A few questions/comments...
Not sure what you mean by this? What kind of masks?
Have you seen Decal Layers? They're intended for this use case. The documentation on them isn't super great at the moment though.
You can already add Level Values to your project that you can set for each map. Is that what you mean?
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.
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. :)
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
We don't currently use OpenFL or Kha. It's all WebGL / jQuery / HTML5-y goodness. Unless I'm misunderstanding what you're saying? |
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.
I have not, but I don't imagine they have some of the other suggestions I edited recently!
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
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.
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!
All good, it's only to improve the RAPID side of things - not a key feature haha
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! |
Looks like I was talking about the grid editor or something . . . I guess I don't understand the editor too much. |
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. |
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... |
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 :) |
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
Settings, but for the individual level/mapAdvanced Feature Requests
Integrated, very basic, pixel-based sprite editorwould prefer it to be feature-light weightIE: colors, opacity, basic shapes + line, eraser, bucket, pixel size, frames, copy paste, and png export . . .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!
The text was updated successfully, but these errors were encountered: