2020 Project Direction

(Fletcher) #13

Thanks everyone for the feedback. It sounds like there’s a few major issues that need to be decided, and then streamlining and enabling contributions.

Let’s see what we can do to fix some of this! If anyone is interested in participating in some cleanup/streamlining efforts, please post here.

I’ll make another post as we work through the bigger decisions

(Timon) #14

I can’t really say, it’s quite a radical change which likely will have an effect on the community. Maybe positive or negative.

Rust already has a community discord and a game dev discord. Maybe it isn’t that bad of an idea. If all amethyst related things are discussed there then the rest of the rust community will be indirectly involved. Wich might spark contributions. An other option would be to create a channel in rust game dev.

(Thomas Gillen) #15

I have been spending just about all of my free time (and some time I should have been spending elsewhere) on the experimental branch in legion, which is now close to feature parity with master (and is a significant improvement in both code quality and performance). I was planning on switching my focus soon to working much more closely with @aclysma and @kabergstrom on getting their serialisation and editor work properly integrated, and then moving my attention over to more directly contributing to helping out with Amethyst itself. I am also willing to move the legion repo over to the amethyst org and hand over more control of the project.

I do not really know what would be best for the Amethyst project for the immediate future, though, and understand that a switch to legion is taking longer than expected and is a blocker for other work. Hopefully once I can shift my attention over to more directly assisting with Amethyst things might pick up pace.

@chemicstry I don’t really want to derail this thread here, but the performance cost for inserts and changes is, I think, overblown. For entity insertions, legion’s experimental branch is pretty fast (inserting 10,000 entities with 2 f32 components):

legion-master insert time: [589.54 us 592.71 us 596.27 us]
Found 4 outliers among 100 measurements (4.00%)
4 (4.00%) high severe

legion-packed-archetypes insert soa
time: [47.888 us 48.051 us 48.266 us]
Found 2 outliers among 100 measurements (2.00%)
2 (2.00%) high severe

And I have been doing some experiments around component insertions/removal and found that if you have components that are added and removed at a high frequency (which 90% of the time are when you are using components as state transition flags), using an Option<T> as your component is much faster for both setting/unsetting and iteration speed than actually adding or removing the component in other ECSs. If you have extremely low occupancy and your components are large, you could alternatively store these components side-channel in a hashmap or sparse array resource, which ultimately ends up being very similar to what other ECSs do to acheive faster insertion speeds.

6 Likes
(Khionu Sybiern) #16

Regarding the Discord, if we’re about to do a revitalization of the project, cleaning up the Discord would add to the visibility of that energy. I have been opposed to doing larger structural changes to the Discord until it such a revitalization occurred.

Changes I’m mulling over:

  1. Archiving (public read or serializing/zip) the entire Development category
    • While it is a large step, we’ve wanted to use the forums as the primary conversation platform when it comes to actual development work. The Development category was supposed to be for work on the engine as opposed to consuming the engine, and that doesn’t make a lot of sense to have along side the forums, especially since it attracts a lot of people seeking support.
    • My alternative is to put the whole category behind an “opt into the Development channels” wall, which would be as simple as clicking a Discord Reaction. In that wall, we could explain what the Development channels are for, and encourage people to use the forums instead.
  2. Create more support/discussion channels for consumption, move Game Creation be more for users to showcase their work.
  3. Get rid of the Language Category.
    • As a Verified Community, we have certain moderation obligations. Unless we have at least one person who is taking on moderation responsibilities who knows a given language, we can’t moderate them.
    • Additionally, aside from French, none have gotten more than a handful of messages in the last several months, and even French hasn’t had that much activity.
5 Likes
(Kae) #17

I made atelier-assets for use within Amethyst, but unfortunately the current prefab system loads stuff in-line based on paths, so it wasn’t compatible with atelier-assets. I didn’t want to push for an integration of atelier-assets that couldn’t reach feature parity with what’s already in, so I made a new prefab system for legion. The new prefab system (https://github.com/kabergstrom/prefab/) is similar to Unity’s prefab system in its design. It’s hard to support a prefab system like this in specs because specs doesn’t support working with component types generically using component type IDs and pointers. Specs’ Storage APIs don’t expose this, and this was also a hinderance to accessing data from scripting languages.

4 Likes
(Khionu Sybiern) #18

This is another big point. Others noted that sharing access to Specs-owned content was a complicated matter over FFI.

1 Like
(Azriel Hoh) #19

As long as enough people are active, focusing on Legion is better for the longer term – WASM still needs polishing from the lower level libraries (like, as basic as the wasm-bindgen level).

The risk is that there is hype now that a heavy decision is being made, and after the hype goes away, will the development continue to be consistent? I think it can – let’s make the contribution process easier:

  • Don’t require checkboxes on the PR templates – some are really heavy.
  • Allow 1 person approval merges (given enough experience / educated judgement)
  • Communicate! – simply reply saying “sorry I haven’t got time to review this in the next 2 days, can someone else take a look?”
  • Changes as small as required – WASM had heaps of changes, but none larger than necessary to fix “just the one thing”, and sometimes “half a thing”.

Just a heads up, I wouldn’t be able to work in the capacity that I’ve put in for WASM, but I encourage people to use a similar management process (I see the github project is already created). Oh yes, and make sure you have an end-to-end project – you need to know what the consumer experience is like.

p/s: WASM’s always been hyped, and though heroic efforts pay dividends for discovery, it is consistent persistence that actually made it usable.

4 Likes
#20

As I understand WASM is currently blocked on waiting for upstream releases? I know that there are some other big usability issues (and a lot of them is contributing to upstream), but given the now limited resources, I think it’s worth merging WASM when it unblocks, because it brings a lot to the engine like gl support, updated rendy and solves some old issues. There may be some minor work to ensure that it is in feature parity with master. In the mean time I think we can focus on legion and just merge whatever is finished/unblocked first.

And yes I agree with all the points of making contributions easier. Communication one is really important, we are sure not attracting any new contributors by ignoring any attempts.

Regarding discord: I think it has two sides. Fast communication speeds things up, but also a lot of good conversations and decisions get lost in the history. We should encourage development discussion to happen in github and leave discord just for help (also development help).

1 Like
#21

Hello, I am new here, so let me quickly introduce myself and give some background before I get to the point. Sorry if this post gets too long :slight_smile:

My name is Milan, and I’ve been keeping an eye on the Amethyst project for a while now, but I’ve always been very passive, checking the website occasionally to see if there are any news, and trying out the engine whenever I had a little bit of free time (that happens extremely rarely, since I’m a university student with a part time job).

As such, I’m very much a beginner in both Amethyst and Rust and I don’t have a deep technical insight into the engine like most of you guys seem to have. I barely know there is something happening with Specs and Legion - I admit I have not researched these things well enough, so I’m still not sure what kinds of benefits are there. But that is not the point.

The point is that I’m mostly an Amethyst outsider and a hobbyist game developer with a fair bit of experience in Unity and Godot. I want to give you my perspective on how I view Amethyst, mainly from the point of view of a new-ish user. I may compare Amethyst with Godot along the way, I hope you’ll forgive me for that :slight_smile: Also, I may make some incorrect statements and false assumptions along the way, please correct me whenever I do. It’s the result of not following the project closely enough.

That’s it for the introduction, now for the main part:

It has already been mentioned that the engine is hard to use. I agree completely. But it is not just the API or the documentation. What I miss the most when coming from, say, Godot is the editor. In my opinion, an editor makes a huge difference in usability and I would say it is essential to have it in any real-world project.

I have noticed some attempts at making an editor, but they all seemed both lacking in functionality and abandoned. If I recall correctly, there were two official attempts to make one, with the first one being cancelled in favor of a rewrite which, last time I checked, was inactive and incomplete. I was also stoked when I saw a Blender integration (it was called Arsenal I believe), which I thought was the perfect solution. Unfortunately, that project seemed dead as well.

Amethyst itself seemed to progress very slow in the past months. The latest news were from October last year, which announced Grumpy Visitors. I remember there was also news about WASM, which was supposed to arrive sometime in late 2019 if I remember correctly. Whenever I opened Github, all the latest commits seemed to simply fix typos here and there.

I know this is a project people are working on in their free time, but it got to a point where I feared that the project is dead.

I really hope that one day, Amethyst will reach Godot level of activity. Whenever I visit Godot’s website, it feels like an exciting adventure. Whenever I visit Amethyst’s website, it feels like a ghost town.

Last but not least, and this may just be my feeling, but I think Amethyst focuses way too much on low-level technical stuff. Things like Specs vs Legion, WASM, renderers… I mean, all these things are obviously very important. But after all, Amethyst can be used to make games already, right? Why not push for more ease of use (like focusing on the editor for now) instead of going for, say, the most performance possible?

I guess it’s about tradeoffs. As a programmer, I completely understand why one might fall into the trap of playing around with cool shiny technologies. After all, it’s one of the reasons I’m so interested in Amethyst and Rust. But right now, it feels like everyone is polishing the REST API while the frontend guys are nowhere to be found.

I think that if there is a massive push in the usability aspect, more people will start to use the engine, and as a result, more people will be able to contribute. Refactoring and redoing stuff can always be done later - it doesn’t have to be perfect from the start (and it won’t be, no matter how hard we try). I remember that when Godot started out, I hated its editor. It was really clunky and weird, but it was there. And people have been using it. And they have provided feedback. And slowly, feature after feature, it got better. And now, look at where Godot is.

TL;DR version:
I think Amethyst desperately needs more activity, and way more focus on ease of use. Stop trying to be too perfectionist and focus on features that make the engine nicer to use.

That’s it, sorry for the wall of text. I really hope Amethyst succeeds, but I think it won’t if the bar to entry is too high. I hope this post is helpful in some way.

7 Likes
#22

New here. Just to give some direction advice’s.

I barely can do anything in rust. Or in any language really. But I know that Unreal or Unity is just not something I believe in. Or Godot for that matter. (bad 3D and copy allot of Unity’s bad stuff)

First thing for 2020 might be to update stuff to be current year? I mean if you check on Amethyst Home page under “RoadMap” you might get what I mean. The hole project looks like it is at a stand still. Makes one wonder if there is even a reason to look into joining in you know? 4 months out of date is not good. No direction indeed.

Get stuff to be usable. And by that I mean whatever talk about Legion is a mess as someone not knowing anything about the core systems is scared away from whatever is going on deep down in the engine roots. Like is it worth looking into anything while it is up in the air if anything is going to be the same in 6 months? I’m ready to learn but it looks like stuff is in question to change wildly so should I? Or just go somewhere else? Or just wait (as I have for eeeeh 4-5months now) and check back then?

The main reason to use Amethyst VS doing stuff on your own is listed on the .amethyst.rs Yet why go with Amethyst when your leaving stuff undone and up in the air. : / Why not role your own at that point.

Ow and sort out Physics. The pain of most open source game engines are the physics and 3D : c

=== Tip about working with Arsenal ===

I have played around with allot of stuff trying to find something open and powerful enough to stick with and grow with. And out of all game engine related stuff I have tried Armory3D was VERY interesting

Basically due to Blender integration and that everything was done in one language more or less made it stand out as something worth investigating. (and with Blender/a editor your in the right place to do that)

Armory3D is a bit more of a framework then a game engine with a editor if you ask me.
Everything code related was easy to open up and read, and due to being inside of Blender one had more or less everything but Code editor and Gimp at ones finger tips in the “engine”! Big+. So powerful yet way easier to do stuff solo. You can borrow allot from Blender and it is a given a game dev is going to learn some kind of 3D or 2D tool. And right now Blender is king in at least on the modeling side.

Blender UI is not that bad considering all the tasks a game engine needs to be able to do. Agen Armory3D and 2.8 Blender was very much something I had loved to see happen. (UBGE exist I know)
It might not fit everything but it is like the next gen of Unity/Game engine. Having so much of the tool chain integrated together and working together strength to strength while at the same time learning Blender fluidly is grate!

Video editor. 3D modeling. Sculpting. Game engine. Animation. Grease pencil. Blender have ALLOT going for it right now. Open source. Free. EVEE. Visual scripting with Blender Nodes? Not that I like VS.

Blenders biggest drawback was fixed in 2.8. Now only thing naggin me that it sometimes seems slow and probably not the easiest thing to integrate a game engine into. And video editor I find lacking in usability and things vs a real video editor.

Arsenal. <=== Make that thing happen with Amethyst. I’m quite sure that doing it that way vs doing your own editor and stuff from scratch really helps the usability and “beginner” friendly side. But that is just my thought. Not a magic code wizard so do not know the feasibility of things. Just know that Arsenal grinned to a stop due to Amethyst not being there and help it to come of the drawing board. So? Be there pretty please and make that stuff happen! I’m sure advances in Arsenal helps Amethyst to develop. If there is difficult to do stuff in Arsenal improving Amethyst (being the core) is a given no?

#23

First, I think there’s a real chance I’m about to kick a hornet’s nest, so I’m sorry in advance if this steps on any toes or offends anyone. There is clearly a lot of love and thoughtfulness invested in project - both in terms of technical/code and community.

Above all, I think the most important asset that this project has produced has been a community… I hope this is preserved regardless of how the technical side of the project goes.

I think the biggest issue is a lack of focus. Even commercial engines generally pick ONE of these three categories and focus on it:

  • Full-sized Native Games (i.e. PC, full-fat consoles): These use to-the-metal rendering APIs, GBs of memory, and multiple threads. Battery life and asset sizes are not much of a concern.
  • Mobile Titles (i.e. iOS, android, handheld consoles): These can use multiple threads, but usually have to deal with a less modern rendering API (or buggy implementations/inconsistent support), more limited memory, and assets need to be right-sized to be appropriate for a small screen-size and not wasteful/slow to download.
  • Web: These are using very limited resources, immature and poorly supported standards, and need to be even more compact than mobile games.

Trying to target all three of these completely different environments seems out-of-scope for a project with amethyst’s resources. In particular, I believe targeting WASM brings too many compromises, which would lead to a niche product that is only good at games for a very specific environment. (Limited GPU/memory/CPU resource access, web standards that lag the state-of-the-art, etc.)

The legion migration either needs to be completed or cancelled. I think it is a good change to make as long as there is consensus in the community to make the change. I don’t see this as a matter of performance, but as a matter of being more user-friendly, more ffi-friendly, and being designed with streaming data in/out of the world in mind.

I’m hesitant to bring up the editor/UI… partly because whatever I say will likely be controversial and because the first issue - choosing a target - is way more important. First, there needs to be a decision on if there is going to be an editor or not. Designing an engine around having an editor but not actually having one is going to cause problems. If there is going to be an editor, it needs to be easy and low-friction to build new tools into the editor/UI. That means the implementor should be able to write their feature in rust, and the editor tools for that feature in rust. If the contributor has to be familiar with web technologies, this vastly reduces the number of people who can easily contribute improvements to the editing experience. It should be based on a stable and proven API like dear imGUI. The current approach brings a lot of complexity to an already high-risk component and in my opinion will make contributing to the project more difficult.

I think all of these issues have led to the technical aspects of this project stalling out. Every project has a “risk-budget” and these issues have clearly led to that budget being exceeded. Even a funded commercial game studio would struggle with this level of technical risk.

Regardless of where the project goes from a technical side:

  • I think the amethyst community has been and continues to be a huge asset to the rust game development community. While I personally have chosen not to use amethyst “the engine” for some of the above reasons - this community has produced and continues to maintain many crates that are important to the ecosystem. Many of these crates start out as single-person projects, and having a place to transition them as they mature is incredibly important and valuable to the broader rust community.
  • Additionally, this community has provided a path for both new-to-rust game developers and new-to-gamedev rust developers. It’s not a perfect path - but in this case I think the effort and care from the community that can be clearly felt is more important than the result.
8 Likes
ECS Designs and The Vision of Amethyst
#24

Really amethyst should not have a editor. And not cater to Mobile Titles. I mean if the engine is efficient and not very taxing to begin with it, more or less is will be catered to the mobile already. Just not purpose made like some more out of the box stuff out there. (Unity) If someone care enough about making a good mobile game they are going to seek out Amethyst or something powerful low resource. If they are lazy they go with something easy instead that just works. :laughing:

If focus is on high end and Web I think everyone is a winner. As making a powerful Web engine is not a bad fit for Rust and WASAM or what it is called. (not interested in Web so not any good at it) I rather think that Mobile = Web. The first Iphone was meant to not have apps outside of calculator and such. They imaged stuff being web based and not application based.

Amethyst is a really bad search therm btw. (are we games yet => I get to Amethyst)
I really think Amethyst should be used to build something on top of. And by that making categories possible and still keep focus on a a single thing. Also it can boost the contribution and advancement all around if one project is about the frame work and the other on a game engine.

If it is made to be a big tasty framework for stuff to be built into something like a Godot/Arsenal, yet leaving room for someone to build there own game from a nicely product ready framework instead of everyone running off reinventing the wheel. Profit? If the framework can not make a game engine possible then what use is the framework. And what is the point of working on something like a editor if all someone wants is to not role there own Vulkan and Web stuff. Amethyst should make stuff work cross platform and fast. The “magic” if you will. And something else should be using it to make a game engine that then is used to make games!
FR = ENGINE = Game!

Hits all the right tick boxes making amethyst not a big unnecessary big pile 1 fit all thing. Better to branch and use Amethyst as a base building block for specific purpose jobs. (that being FW or full blown ENGINE.)

No?

Have a nice day!

1 Like
(Thorlucas) #25

Also a newbie at Amethyst — posting this here not to be a dick, but because I care about this project and I would like to see it viable for use in game dev soon:

Amethyst has some really strong points. It’s biggest selling point in my opinion is the ECS system. It’s a delight to work with most of the time, and it feels good to develop in. Whenever I write code in amethyst it feels tight and well structured. That’s a very, very good feeling for any programmer to have, and it really instills confidence.

The biggest downside is unfortunately rendering, and it’s the reason I just can’t use amethyst for any project I hope to release (even if just a game jam). With a lack of a variety of built in rendering components (basically we just have sprite and ui?) it needs to be as easy as possible to implement new rendering components. Unfortunately, its ridiculously difficult.

I implemented a custom shader and it was a nightmare. I had to define a new rendering pass, copy a ton of boilerplate code I didn’t quite understand, build up my own tris, etc. It really needs to be as easy as possible to define custom shaders, and unfortunately right now in amethyst it’s about as low level as it can get. I never want to do it again, and to be honest it’s the main reason I haven’t used amethyst since.

Second is 2D hierarchical rendering, and from what I understand amethyst does not support this. For example, if I have some entity, and two child entities, these two child entities need to be drawn on top of the original entity in 2d. AFAIK right now you have to do this by explicitly setting the Z of the transform? That’s bad. It takes a long time to get this working, and that’s valuable time wasted for a developer doing a game jam or something. In fact, needing to specify a Z position in general is not great. Why don’t 2D objects use 2D transforms?

Third is the 3D currently looks like garbage. Again, I don’t mean to be mean, but honestly it does not look good. This NEEDS to be a high priority. Look at Evoli — its a super cool project, but it looks bad. Nobody will opt to use amethyst for 3D because it just does not look good.

There are several more grievances I have with amethyst, but those are probably the top 3 and they all come from the same category: rendering. The ECS right now is very good. Legion I’m sure would be great, but I don’t think it needs to be priority. WASM is fairly important because without it game jams are impossible (nobody, I mean NOBODY will download your game if it doesn’t run in the browser). But really, the top priority in my opinion should be sorting out the rendering engine to make it more end-user friendly.

5 Likes
(Martin) #26

Could I suggest working on documentation and examples? Please look at Amethyst from the viewpoint of a game author who wants to turn a game concept into a working game. They need to understand all of the game engine, from the point of view of how do I make Amethyst do this? And that documentation is just not there at the moment. Also, we need documentation and examples for all the features. Otherwise, if a feature is not documented, from the game author’s point of view it does not exist.

6 Likes
(Fletcher) #27

A quick update on this topic…

We’ve finished the WASM project and accompanying obligations to Mozilla. We’re going to finish the Legion integration as quickly as possible, and then focus on reducing friction for users, better documentation and examples, and similar things.

@martinellison and @thorlucas (and others above) make excellent points which echo what we’ve heard for quite some time now. I’ll post again once we are closer to a post-Legion roadmap; in the interim, please feel free to continue posting quality of life suggestions here.

9 Likes
(Nathan) #28

I was recently invited as a trusted contributor (thanks!). This discussion has been very helpful in getting me up to speed with recent events. I’ve been lurking for a couple years until I recently decided to start getting more involved.

I encourage extending the trusted contributor invitation to anyone who begins getting involved in any meaningful way.

While I’m on the topic of new trusted contributors: For a healthy, long-term community of volunteers that come and go, we need to continually work on improving the onboarding (and offboarding) process. We’ve got a good start with some of the files in docs/, but we seem to be mostly in the “read a few things we wrote…and then just jump in and read all the code and figure out what you can help with” stage of onboarding maturity. I think the use of GitHub project boards for people to swarm on something large-ish is a step in the right direction.

Also, in the spirit of improving things…

I opened a PR to update docs/CONTRIBUTING.md to align with this suggestion. I’d love feedback, discussion, or review approval(s). :smiley_cat:

4 Likes
(Nathan) #29

Yes, please! I am in favor of anything that decreases the huge number of Discord channels. It is very hard to figure out where to go to discuss things, since there are tons of options.

2 Likes
(Hugo Lindsay) #30

Hi. I’m pretty new, but willing to contribute in any way that I can. I have a few points:

  1. Let’s merge a bunch of unused channels into a single channel on discord for communication on dev of the amethyst ‘current focus’ project. (Which I understand to be legion right now) The discord channel can be called something as simple as dev-focus. This should be the single one and only go-to communication method for dev on the ‘current focus’ project. It’s too difficult to coordinate over multiple communication methods.

  2. Let’s update the project title from “Legion integration” to “Legion integration (current focus)” here: https://github.com/amethyst/amethyst/projects

  3. Let’s make sure the project is well scoped and kept up to date here: https://github.com/amethyst/amethyst/projects/21

  4. Let’s have a weekly status update call on discord to help stay in sync. Let’s keep it to the same day and time every so it’s easy to remember.

Now, most importantly, for each of my 4 points, who do I need to follow up with to get things done? (or alternatively, who can give me the access required to get them done?) Thanks!

2 Likes
(Khionu Sybiern) #31

I’m thinking, in addition to these changes, a channel specifically for help migrating from Specs to Legion, and a singular #contributing channel.

3 Likes
(Lochlan) #32

Hi all. Not sure how much value I can provide, but I want to share a few observations in no particular order. Please excuse my brash candor!

  • Who can be the person in-charge of this right now? Call this the “back on track” sprint and elect someone as the sprint manager to badger the hell out of everyone else to get their parts done ASAP. The pay off is everyone getting to return to what they’re most excited about.

  • Amethyst is awesome, and it’s fairly unique in the Rust space for its maturity. Users see that and they want to invest in it.

  • The project has good bones. Whatever happens next wrt focus, I think everyone can get excited about. There’s tons of stuff on the horizon that us users are super excited for.

  • I think I spot some idea/feature churn fatigue, which is normal for big open source projects. Don’t let that hinder your personal vision for what you want to build next (this goes for users too!)

  • There’s plenty of current users who are looking at this framework as a long term investment. That decision is made easier when we see contributors rallying together around shared vision/milestones. I think there’s plenty of people who are ready and willing to be contributors once the dust has settled a bit. The faster the decision about direction/next steps is made, the faster the community gets hyped. Right now this is all moving at a snail’s pace!

  • If you haven’t already, you should formalize a vote amongst current contributors on Legion vs. Specs and then all commit to the result, so that everyone can take ownership of its success/failure. It seems like there’s still some doubt about Legion’s future? Probably need to clear that up. Legion seems like a huge mental blocker and/or demotivator for everybody because of how it impacts their projects/feature. Committing to its future one way or another might help break those mental blocks.

  • Consider halting development on auxiliary features/improvements until the core task/focus is completed. The sooner the ECS problem is answered the sooner everyone gets their motivation back to work on their own pieces, add will know exactly what is required for their work to get merged.

  • Switching (or keeping the existing!) ECS now or later doesn’t matter that much, it’s going to be a PITA either way, so don’t get too attached to your position. “Strong opinions, weakly held.”

Aside from all that I just want to reiterate and extend a huge thanks to everyone working on this project. I’ve done some open source stuff in the past and know that it’s often a thankless job. Your work is not going unnoticed. There are many lurkers who are deeply grateful for your contributions! Looking forward to seeing what can be achieved this year.

5 Likes
Step 2: After the Vision Comes Leadership :busts_in_silhouette: