-
Notifications
You must be signed in to change notification settings - Fork 404
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
osu! markup language #30
Comments
How about parsing it at runtime instead of complicating the build process with additional tools? We can use Reflection.Emit when we compile YAML so that the runtime cost is low. |
it will have runtime parsing support, but we need c# code so we can intellisense and use stuff it creates, i believe. |
I see. Sounds good. |
Is it a correct assumption that Can a top level node be cut and pasted into a |
In one file. Can you give a use case for needing to copy-paste top-level nodes? |
If it acts as inheritance, maybe renaming it to |
Funny that, I had extends in my original proposal. I totally agree. |
I was thinking about ease of definition for children. Sounds like you got it handled. 👍 |
Are states defined by the objects themselves or just the behaviour of each state for that object? Is there a set of predefined states and we are just defining how they should behave in this state? If that's the case are user defined states allowed? Are transitions defining behaviour by default?
This is what I understand: HoveredTransition is basically saying when this is applied transition between the original state to the hovered state in 500 time units. But then ScaleTransition simply says that when you apply this scale the object by this amount, directly changing the state with no additional information provided. (Equivalent to something like: What I am asking is: Is there some sort of predefined behaviour when a transition doesn't provide any information about how it should transition? If there isn't any (which I assume it is the case) then you can implicitly define empty transitions for states. Example:
This will implicitly have a "ScaleTransition" that would be the equivalent of writing:
|
There should be a way to define the transition type, i.e. CubicOut, Exponential, etc.. Possibly defaulting to some value if not set |
|
It seems that this isn't going to be necessary. |
Reopened at request of @phosphene47. We still need this for (at very least) skinning – cases where we want to accept runtime-parsed drawables and a secure way. |
We could also use JSON, right? I think JSON.net would allow us to parse this data at runtime and directly populate an existing container (+ we already have the parser included in the nuget packages). |
yaml is a superset of json so we automatically get json support from yaml parsers (https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json-when-to-prefer-one-over-the-other). no need for json.net we can't simply directly populate existing the only drawback to emitting at runtime is cross-platform incompatibility (specifically iOS). |
It's definitely a consideration we need to keep in mind, since skins still need to work on iOS. |
I may look into doing this, got some questions. Some of these are implementation details so I'm not sure if I'm supposed to chose these myself or not.
|
Since this was written, the scope has definitely changed. The primary use case is not for skins and such, where we want to allow users the ability to customise without the ability to break. They would only be able to touch properties exposed by a specific interface or attribute marking (and we would need to define these interfaces for clases which wish to expose them to the user).
|
I personally would prefer a markup language that allows following yaml code: # Skin usecase: Backbutton
Target: Backbutton
Box:
Width: 200
Height: 50
Colour: Red
Alpha: 0.7
Origin: LeftBottom
Anchor: LeftBottom
OnHover:
- Scale: 1
To: 1.5
Duration: 300ms
Easing: InQuint
- FadeTo: 1
Duration: 300ms
Easing: OutQuint
OnClick:
- FadeTo: 0
Duration: 100ms
Children:
- SpriteText:
RelativeSizeAxes: Both
Width: 0.6
Height: 0.6
Anchor: Centre
Origin: Centre
FontColour: White
Text: "Go Back!"
---
# Skin Usecase: Healthbar
# Predefined variable:
# $healthValue
Target: Healthbar
Box:
RelativeSizeAxes: Width
Width: 0.3
Height: 100
Anchor: TopLeft
Colour: Black
Alpha: 0.9
OnUpdate:
- FadeColourTo: Red
Condition: $healthValue < 0.3
Trigger: Condition
- FadeColourTo: White
Condition: $healthValue >= 0.3
Trigger: Condition
Children:
- Box:
RelativeSizeAxes: Both
Width: 0.9 * $healthValue
Height: 0.3
Origin: Center
Anchor: Center
Colour: White Each yaml document targets an ingame element. The
|
Gonna close this issue to start afresh. |
Initial draft spec of OML. It's changed a little bit since the last iteration in the transitional repository so you'd best go over this again and point out any inconsistencies/points of clarification or just general comments. Topic for the next pair programming session.
OML - osu! markup language
What is OML
OML is a markup language very similar to QML, oriented towards designing layouts for games that are built upon the osu!framework. The language is YAML-Validated and generates appropriate C# code upon compilation.
Basic syntax
The following is an object that represents a 100x100 red rectangle:
Width
,Height
andColour
are general properties of the Rectangle. These are applied when the object is constructed.Special Properties
Objects have special properties:
Extends
States
Transitions
Events
Properties
Children
The
Extends
PropertyObjects extend
Drawable
by default and inherit all ofDrawable
's properties. It is possible to change this behaviour where this is not intended by specifying theExtends
property of the object:The
States
PropertyA state defines how an object looks at a point in time by modifying the value of the general properties of the object. This special property may be used to define named states which may be referred to by multiple places in further code.
The property named "Default" is optional but will be applied when the object is first constructed.
The
Transitions
PropertyA transition defines how an object should transition towards a state. This special property may be used to define named transitions which may be referred to by multiple places in further code. These can be used to transition to either named or anonymous states.
The
Events
PropertyAn event defines the transitions that should be applied to an object when the event is called. Events are exposed in the generated C# code. These can be used to apply either named or anonymous transitions.
Todo: Reserved events
The
Properties
PropertyAn object may define properties as private members for it to use.
The
Children
PropertyAn object may be composited by several children that are directly affected by the containing object. In this way it is possible to transition an object and all of its children together by applying the transition to the containing object.
Children may be either named - allowing them to be referenced as private members from generated code, or anonymous.
The text was updated successfully, but these errors were encountered: