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

About the simplicity issue #1152

Open
torkleyy opened this Issue Nov 15, 2018 · 9 comments

Comments

Projects
None yet
9 participants
@torkleyy
Copy link
Member

torkleyy commented Nov 15, 2018

It's a rather broad opinion that Amethyst could be simpler to use. This makes our engine less appealing for smaller games. I'm hoping to bring in everybody who shares that concern, and to start off a discussion about how we can make Amethyst simple to use, while keeping the flexibility aspect.

This thread emerged from a discussion on Twitter.


The issue

A major goal of Amethyst is to be highly customizable for the individual needs of a project. This is what I just use "flexibility" for most of the time. This includes things like

  • replacing a part of the engine
  • opting out of default behaviour
  • structuring your game different, maybe without states, or with very different ones, etc.

That's one side of this. The other is: people want to make simple games, like Pong, Tetris, etc. Dealing with generics, multiple lifetimes, etc. is not what is expected for this.

A bit of history

Amethyst used to be a just a few crates (mostly just the main crate) a long time ago. At some point, the sub-modules mostly moved into their individual crates. It was clear at that point that any Application wrapper would most likely not be able to cover all possible use cases, and we hoped to make the main crate an optional facility that gets you started quickly, but is simple, so that bigger projects should use the individual crates and not the main one.

Now, I think this was not communicated very clearly, and I understand it just makes sense that you want to continue using the main crate to have a certain feature. This has led to more flexibility being added to what used to be rather simple abstractions, and as such, the main crate became rather complex. We are providing a bunch of simplified variants for some things, but that creates its own problems, such as

  • being too simple, and thus not allowing important features
  • additional maintenance work
  • the need for more documentation and potential confusion because of all the options available

I think this is a hard discussion and needs some thorough thinking. The solution for this is most likely far from trivial, but please don't hesitate to add your ideas here!

@jojolepro

This comment has been minimized.

Copy link
Member

jojolepro commented Nov 15, 2018

Related issues:

#1148
#1114
#1101
#1086 (2D render unification fixes this)
#1080
#1044 (Priority)
#989
#986 (Priority)
#951
https://github.com/amethyst/amethyst/issues/762
#460
#429 (Hopefully fixed in 0.11 with rendy...)
#142 (Heavily requested)

@minecrawler

This comment has been minimized.

Copy link
Contributor

minecrawler commented Nov 15, 2018

What exactly is the point here? What do you want to discuss? How to make Amethyst more appealing for a broader audience? How to improve communication/documentation?

imho, when making a simple game, Amethyst delivers a lot of things which are simple to use.... once you wrap your head around all the concepts. Amethyst is not like SFML or similar, which many people creating small games might be used to. It delivers very scalable architecture for games. And it is not C. It is Rust, and Rust adds many hurdles. Things which might be faulty, but still work in smaller applications are not possible in Rust, which might add to frustration. As such I never even considered Amethyst to be made for small games. If you want to create a Space Invaders clone, there are better solutions. And let's be honest here, none of them is native. Platform independence and system languages are a pain, when WebGL delivers on all modern browsers on all platforms and can be integrated into native apps if necessary (Electron, Cordova, etc.)

So, since you say that Amethyst does not appeal to creators of simple games, then yes, I never thought it should in the first place. Catering to everyone is impossible after all. If you want to appeal to game devs for very small and simple games, then you'd have to abstract a lot of things away and focus on a very different set of features.

As such, I think you should draw a clear line and decide on the audience for Amethyst. Which is not to say that Amethyst cannot cater to small games... just not as Amethyst itself.

Imho, if you want to appeal to game devs with simpler needs, a wrapper library may be created, which does the hard parts and implements the necessary niceties for simplicity, so that simple-game devs just call very simple functions in order to get up and running. Your typical example then should be <10loc to get a window open and render a triangle.

@Xaeroxe

This comment has been minimized.

Copy link
Contributor

Xaeroxe commented Nov 15, 2018

I believe what's being discussed is this publication: https://alexene.github.io/2018/11/15/Rust-and-game-development.html

@erlend-sh

This comment has been minimized.

Copy link
Contributor

erlend-sh commented Nov 16, 2018

Maybe the tutorial could be changed to actually make more mistakes on purpose, in the style of
https://kyren.github.io/2018/09/14/rustconf-talk.htm

I.e. start off with the simplest solutions that don’t actually scale but get things working in a way a beginner understands, and then gradually come back and fix those things as the tutorial progresses.

@AlexEne

This comment has been minimized.

Copy link

AlexEne commented Nov 16, 2018

Hello,

So I as I was asked to provide some further thoughts about it here.

I think the answer to this is: it depends on what the target audience / problem space is. To me, when I looked into rust engine space, it was unclear what the target customer/project is.

Most engines start as something specialized for a specific game or well defined use-case, and they get extended and so on as time passes.
I think repi from (now) Embark Studios made a similar point about this somewhere in this thread: https://www.reddit.com/r/rust/comments/9viryw/embark_a_newly_found_game_studio_will_build_their/

And it's alright if it's not supposed to target the space Unity targets and it goes more towards Unreal. It's basically a choice that the maintainers have. And I do agree, there are always tradeoffs to be made and it's impossible to cover all use-cases.

Thanks,
Alex

@re-l124c41plus

This comment has been minimized.

Copy link
Contributor

re-l124c41plus commented Nov 16, 2018

I sort of agree with @minecrawler here.

Amethyst already provides some simplifications to reduce friction for basic games (also useful for tutorials) and most of them revolve around providing a "configured sensibly and ready to go" version of structures. But those are really spotty abstractions. Some things are simplified here and there but a lot of things aren't.
Providing a pleasant and frictionless experience for simple games requires some dedicated work and also maintenance.

You essentially need to build a basic "surface" for people to interact with and the key here is wide coverage. Single spots don't help when users need to combine them with more advanced parts of the engine anyway.

A good place to start looking is all the utility functions and abstractions that people have started building for themselves. Perhaps one could compile them, generalize and harmonize them, and then release them as one package to provide this "basic interface".
The community probably doesn't yet have enough of those to construct an all encompassing package and I also don't know how much work this might need (also considering the rapid pace of change in the engine right now).
But once you have something like that, building simple games can be done entirely from provided building blocks for common game elements. Once you run into the limits of that you can then still explore how those blocks are working and learn to build something custom.

I don't know how much of Rust itself you can easily hide though. I think many people are not just running into issues related to learning game development or learning the engine, but also Rust as a language.
The issues kind of multiply their effects.

"Entities, systems, components, state machines? Wow fancy stuff. Oh and then there are Traits, all these type parameters I need to put there, and why are these lifetime things here?
Actually I only need some movements, and collisions, perhaps health...guess I'll make that myself, but now the compiler is shouting at me for some reason and spits out lengthy type signatures and lifetime erros that trace back to something behind the scenes that I don't quite understand yet."

See what I mean?
I guess ready made features like I proposed above are the key to avoid friction with the compiler as much as reasonably possible, because you have less room for creating errors when the provided abstraction already does half the work of what you want to accomplish.
But that obviously has its limits and requires work to provide.
Unreasonable alternatives, at least as far as I can see, are to provide (almost) entirely parallel implementations. Essentially something un-generic, limited, but simple to use and less complex in terms of Rust knowledge required.
But I call this unreasonable because how much work this might take to create and maintain.

Ultimately, I think the community will naturally acquire some common knowledge about pitfalls, generally applicable solutions etc. We already see it right now with people discussing and sharing their utility snippets.
In the end we might see a pattern crystallize that can be provided as the solution in a package like I describe above. The set of solutions will grow; FPS controllers, health systems, asset loaders, autosave systems...

@Xaeroxe

This comment has been minimized.

Copy link
Contributor

Xaeroxe commented Nov 16, 2018

Hey guys... get pumped. This got stabilized in 1.31 and I believe it will allow us to drastically simplify our lifetimes in specs.

rust-lang/rust#54778

Usage: rust-lang/rust#54687

@OvermindDL1

This comment has been minimized.

Copy link

OvermindDL1 commented Nov 16, 2018

I.e. start off with the simplest solutions that don’t actually scale but get things working in a way a beginner understands, and then gradually come back and fix those things as the tutorial progresses.

I'm personally always been a fan of Correct Proper Examples, but if at all possible extract the repeated parts between examples into another shared file for them all to use after the example that introduces their concepts.

@jojolepro

This comment has been minimized.

Copy link
Member

jojolepro commented Nov 16, 2018

@Xaeroxe YEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEES!!!

SimpleState will be simple!
I hope this will work with SystemData too!

bors bot added a commit that referenced this issue Dec 3, 2018

Merge #1198
1198: Remove lifetime from `SimpleState` and `SimpleTrans` r=torkleyy a=torkleyy

Fixes #1178 

Related: #1152 

Co-authored-by: Thomas Schaller <torkleyy@gmail.com>

bors bot added a commit that referenced this issue Dec 3, 2018

Merge #1198
1198: Remove lifetime from `SimpleState` and `SimpleTrans` r=torkleyy a=torkleyy

Fixes #1178 

Related: #1152 

Co-authored-by: Thomas Schaller <torkleyy@gmail.com>

bors bot added a commit that referenced this issue Dec 4, 2018

Merge #1198
1198: Remove lifetime from `SimpleState` and `SimpleTrans` r=torkleyy a=torkleyy

Fixes #1178 

Related: #1152 

Co-authored-by: Thomas Schaller <torkleyy@gmail.com>

bors bot added a commit that referenced this issue Dec 4, 2018

Merge #1198
1198: Remove lifetime from `SimpleState` and `SimpleTrans` r=torkleyy a=torkleyy

Fixes #1178 

Related: #1152 

Co-authored-by: Thomas Schaller <torkleyy@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment