refactor: Make game data pluggable #691

Rhuagh · 2018-05-01T18:29:07Z

Remove Dispatcher from Application, and add a pluggable generic type.
Add a direct replacement for the old game data, featuring only a Dispatcher.
Make the states take a new StateData type, containing references to World and pluggable game data.
Move responsibility for doing system dispatch to the states.

Opening this early to get feedback.

Resolves #576

This change is

AnneKitsune · 2018-05-01T21:17:41Z

I'll need a more complex example to really get the feel of it.
Maybe an example with:
-Global systems
renderer,input,ui,assets
-StateLoading
waits for assets to be all loaded, shows a ui specific to this state (loading ui), which get removed automatically when changing state (because when you switch you lose this World)
-StateGame
simple ui showing the loaded asset

The prototype looks good ;)

Rhuagh · 2018-05-02T06:02:10Z

The World is not replaced, it's just the Dispatcher that's been replaced with a generic type.

Rhuagh · 2018-05-02T07:29:39Z

I was thinking of maybe adding a loading state to the renderable example, since some of those assets take a while to load in debug mode.

Rhuagh · 2018-05-02T15:17:28Z

This is basically my stab at #576.

Because we use World for a lot of things internally in Application and a lot of the core, my proposal is basically to keep the core World in place, and simply abstract away the Dispatcher, and any "extra" data that the user might want to keep centrally. The naming of the different types could use improvements, but the core concept is solid I believe.

Xaeroxe

I was pleasantly surprised with how this turned out.

LGTM!

Xaeroxe · 2018-05-03T16:00:51Z

I think it might be a good idea to add a chapter to the book called Advanced Game Architecture that shows how to use multiple dispatchers in a custom GameData structure.

Rhuagh · 2018-05-03T16:37:31Z

I was planning on creating an example atleast once I get some feedback on the basic design :)

AnneKitsune · 2018-05-03T17:58:00Z

I'll re-review it soon.

torkleyy

I like it, thanks for your work! A chapter would really be helpful, I'm not sure I understand how all the *Data types interact exactly.

torkleyy · 2018-05-04T08:18:07Z

amethyst_animation/src/util.rs

-    controls.entry(entity).unwrap().or_insert_with(AnimationControlSet::default)
+    controls
+        .entry(entity)
+        .unwrap()


This should not unwrap but return the error.

That's a known (and reported issue), yes, will fix that in a separate PR as it changes the API.

torkleyy · 2018-05-04T08:24:05Z

src/game_data.rs

@@ -0,0 +1,240 @@
+use std::sync::Arc;


Missing top-level docs

AnneKitsune

That looks good, but since this is a really big breaking change, I have a few questions.

Main one:
Is it possible to have a GameData that has:
global_dispatch
state_specific_dispatch
where the state_specific_dispatch is created during a State start() method?

Basically, sometimes you want to have systems run only for some states (like in this example), but you want the state to conditionally set the systems. Also, creating it in the start (or similar) method makes it easy to find the relation between State and state_specific_dispatch.

I don't want to have
GameData
-global_dispatch
-state1_dispatch
-state2_dispatch
-state3_dispatch
-state4_dispatch
Especially since sometimes creating a System might need data loaded by a previous state. For example, a System specific to GameMode1State would require a Handle loaded by LoadingState.

AnneKitsune · 2018-05-04T12:29:06Z

amethyst_ui/src/layout.rs

-        (entities, mut locals, parents, anchors, stretches, screen_dim, hierarchy): Self::SystemData,
-){
+    fn run(&mut self, data: Self::SystemData) {
+        let (entities, mut locals, parents, anchors, stretches, screen_dim, hierarchy) = data;


Any reason for this?

Formatting. The previous code complained about too long row every time I ran rustfmt, and I got tired of it.

AnneKitsune · 2018-05-04T12:49:00Z

examples/game_data/README.md

@@ -0,0 +1,5 @@
+# Renderable Example


s/Renderable/Game Data/

AnneKitsune · 2018-05-04T12:53:32Z

examples/game_data/game_data.rs

+use amethyst::{DataInit, Error, Result};
+use rayon::ThreadPool;
+
+pub struct GameData<'a, 'b> {


I got really really confused, because this custom GameData has the same name has amethyst::GameData. I couldn't figure out why this one had two dispatchers and the other one had one.

Please rename it to CustomGameData.

AnneKitsune · 2018-05-04T12:55:12Z

examples/game_data/main.rs

@@ -0,0 +1,583 @@
+//! Demonstrates how to load renderable objects, along with several lighting


I doubt it!

AnneKitsune · 2018-05-04T12:55:25Z

examples/game_data/main.rs

+//! Demonstrates how to load renderable objects, along with several lighting
+//! methods.
+//!
+//! TODO: Rewrite for new renderer.


hmmmmmmmm :P

AnneKitsune · 2018-05-04T12:56:59Z

examples/game_data/main.rs

+
+mod game_data;
+
+struct DemoState {


I think having all the lighting stuff makes the example way more complicated than how it needs to be. Its harder to really spot what GameData does when there is so much unrelated code. A simple rotating cube with a fixed camera is all you would need I think.

The renderable example is the only one where loading is slow enough to actually warrant a Loading state, that's why I chose it.

You could keep the .obj loading, which is the slow part, but remove the lights. If not then its fine.

AnneKitsune · 2018-05-04T13:02:42Z

examples/game_data/main.rs

+        data.data.update(&data.world, true);
+        match self.progress.as_ref().unwrap().complete() {
+            Completion::Failed => {
+                println!("Failed loading assets");


printerr! or error!

Didn't see a need to pull in an extra crate for an example.

printerr! then?

printerr? Not a part of core rust from what I know ?

Ya sorry its "eprintln!" actually :P

AnneKitsune · 2018-05-04T13:16:15Z

examples/game_data/main.rs

+            .with_pass(DrawShaded::<PosNormTex>::new())
+            .with_pass(DrawUi::new()),
+    );
+    let game_data = GameDataBuilder::default()


Games don't only have a base and a running state. There should be a way to provide multiple systems that are specific to each of the states. Those systems should be added during the state start function, to allow for better logic locality.

Ofc not, but I'm not about to write a whole game in a single example, and this example is for demonstrating a custom game data implementation, not teach people how to structure a game code wise.

AnneKitsune · 2018-05-04T13:17:48Z

examples/game_data/resources/display_config.ron

+(
+  fullscreen: false,
+  multisampling: 0,
+  title: "Renderable Example",


Renderable again

Rhuagh · 2018-05-04T15:33:54Z

It's a generic type without bounds, you can put anything you like in it. Data would be in the World though, so there's no need to "share" that. Personally, I would put state specific dispatchers in the state, and not in a central location.

AnneKitsune · 2018-05-04T16:00:03Z

So GameData is global? If so I'm not sure what you can do with it that you couldn't do using Resource.

Xaeroxe · 2018-05-04T16:26:20Z

@Jojolepro The main thrust of the PR is to permit people to access data in a way that isn't via specs. So this would be for people who don't even want a Resource.

AnneKitsune · 2018-05-04T16:41:42Z

What would be the use case for that?
Is it worth the added complexity?

Xaeroxe · 2018-05-04T16:45:16Z

@Rhuagh mentioned #576 in a comment on this PR (Maybe we should mention it in the opening PR description)

If we go to that issue some helpful context is present. Specifically this quote:

As more use cases for Amethyst begin to explore the virtues and limitations of
the current data architecture some hurdles are beginning to present themselves for
both optimization and flexibility. The current ECS design forces a specific way of
thinking that works for a lot of designs but requires use of anti-pattern solutions
in others. When examining how one would implement a dense voxel map idiomatically in
Amethyst general consensus is that each voxel should be an entity within
the system. While very simple this is not an optimal structure for chunked densely
packed Voxel data accessed by range query. Thus Voxel information would be
relegated to an outside resource with array data and a second ecs world containing
Voxel definitions. The access pattern of this second ecs is random and differs
greatly from the sequential access pattern of the primary ecs iterator.

AnneKitsune · 2018-05-04T16:52:58Z

And how does Resource not solve this? My current plan for a voxel world involves having it as a resource and having Systems use that resource to create entities (optimised) that will end up getting rendered.

For me, this change is replicating what specs Resources is doing already.

Xaeroxe · 2018-05-04T16:57:34Z

Yeah a Resource could be used for this. That means that to me there's one remaining major reason to merge this PR, and that is to facilitate types that aren't Any + Send + Sync.

Rhuagh · 2018-05-04T16:58:23Z

You can't store systems in a resource.

Xaeroxe · 2018-05-04T17:00:04Z

@Rhuagh is correct due to this: https://docs.rs/shred/0.7.0-alpha5/shred/struct.Dispatcher.html#impl-Send

Rhuagh · 2018-05-07T19:27:05Z

Re-review if you can please.

AnneKitsune

Still not a fan of all the lighting stuff, but that's fine ;)

Thanks!

torkleyy · 2018-05-08T14:22:21Z

When examining how one would implement a dense voxel map idiomatically in
Amethyst general consensus is that each voxel should be an entity within
the system.

Didn't we have that discussion before?

torkleyy · 2018-05-08T14:33:16Z

Reviewed 3 of 8 files at r1, 5 of 10 files at r2, 19 of 21 files at r3, 3 of 3 files at r4, 1 of 2 files at r6, 13 of 20 files at r7.
Review status: all files reviewed at latest revision, 10 unresolved discussions.

Comments from Reviewable

torkleyy

LGTM

AnneKitsune · 2018-05-09T15:37:07Z

I thought cfg!(target_os = "ios") didn't work?
anyway
Waiting for label change + build checks to merge. @Rhuagh

Rhuagh · 2018-05-09T15:50:31Z

I still need to add a chapter to the book, and I'm currently focusing on getting specs out.

Rhuagh · 2018-05-09T17:25:32Z

Rebased, squashed, book chapter added. @Xaeroxe feel free to take over.

Rhuagh · 2018-05-10T10:21:57Z

Ready for final review @Jojolepro @torkleyy @Xaeroxe

AnneKitsune · 2018-05-10T10:44:22Z

outside most of the day, I'll review tonight if I can, or tomorow

Xaeroxe

LGTM! bors r+

Xaeroxe · 2018-05-14T15:46:42Z

err actually nevermind, I think this might fail on CI due to some new examples.

…ng the game data pluggable

Rhuagh · 2018-05-14T20:31:58Z

bors r=Xaeroxe,torkleyy,jojolepro

691: refactor: Make game data pluggable r=Xaeroxe,torkleyy,jojolepro a=Rhuagh Remove Dispatcher from Application, and add a pluggable generic type. Add a direct replacement for the old game data, featuring only a Dispatcher. Make the states take a new StateData type, containing references to World and pluggable game data. Move responsibility for doing system dispatch to the states. Opening this early to get feedback. Resolves #576  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/amethyst/amethyst/691)  Co-authored-by: Simon Rönnberg <seamonr@gmail.com>

bors · 2018-05-14T21:29:24Z

Build failed

continuous-integration/appveyor/branch

Rhuagh · 2018-05-14T21:33:51Z

bors r=Xaeroxe,torkleyy,jojolepro

691: refactor: Make game data pluggable r=Xaeroxe,torkleyy,jojolepro a=Rhuagh Remove Dispatcher from Application, and add a pluggable generic type. Add a direct replacement for the old game data, featuring only a Dispatcher. Make the states take a new StateData type, containing references to World and pluggable game data. Move responsibility for doing system dispatch to the states. Opening this early to get feedback. Resolves #576  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/amethyst/amethyst/691)  Co-authored-by: Simon Rönnberg <seamonr@gmail.com>

bors · 2018-05-14T22:48:52Z

Build succeeded

Rhuagh force-pushed the refactor/game-data branch from 31c9e64 to d3404dc Compare May 2, 2018 14:35

Rhuagh requested review from AnneKitsune, Xaeroxe and torkleyy May 2, 2018 20:18

Xaeroxe approved these changes May 3, 2018

View reviewed changes

Rhuagh force-pushed the refactor/game-data branch from c09deea to cbff52e Compare May 3, 2018 19:37

Aceeri approved these changes May 4, 2018

View reviewed changes

torkleyy approved these changes May 4, 2018

View reviewed changes

AnneKitsune suggested changes May 4, 2018

View reviewed changes

Rhuagh removed the status: ready label May 7, 2018

AnneKitsune approved these changes May 7, 2018

View reviewed changes

torkleyy approved these changes May 8, 2018

View reviewed changes

Rhuagh force-pushed the refactor/game-data branch from e4a2357 to f01a340 Compare May 9, 2018 17:25

Rhuagh added status: ready and removed status: working labels May 9, 2018

Xaeroxe approved these changes May 14, 2018

View reviewed changes

Rhuagh added 4 commits May 14, 2018 22:18

refactor: Breaking Dispatcher out from the core Application, and maki…

5bacee4

…ng the game data pluggable

Adding a more advanced example with custom GameData

dcf8a35

feat: New book chapter about custom GameData

6b2440c

Fix arc ball camera example

6d3f65a

Rhuagh force-pushed the refactor/game-data branch from 36cfca2 to 6d3f65a Compare May 14, 2018 20:29

bors bot merged commit 6d3f65a into amethyst:develop May 14, 2018

Rhuagh deleted the refactor/game-data branch May 14, 2018 23:05

Xaeroxe mentioned this pull request May 15, 2018

Make main functions return Results #712

Closed

		@@ -0,0 +1,583 @@
		//! Demonstrates how to load renderable objects, along with several lighting

refactor: Make game data pluggable #691

refactor: Make game data pluggable #691

Conversation

Rhuagh commented May 1, 2018 • edited by Xaeroxe Loading

AnneKitsune commented May 1, 2018

Rhuagh commented May 2, 2018

Rhuagh commented May 2, 2018

Rhuagh commented May 2, 2018

Xaeroxe left a comment

Choose a reason for hiding this comment

Xaeroxe commented May 3, 2018 • edited Loading

Rhuagh commented May 3, 2018

AnneKitsune commented May 3, 2018

torkleyy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AnneKitsune left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Rhuagh commented May 4, 2018

AnneKitsune commented May 4, 2018

Xaeroxe commented May 4, 2018

AnneKitsune commented May 4, 2018

Xaeroxe commented May 4, 2018

AnneKitsune commented May 4, 2018 • edited Loading

Xaeroxe commented May 4, 2018

Rhuagh commented May 4, 2018

Xaeroxe commented May 4, 2018

Rhuagh commented May 7, 2018

AnneKitsune left a comment

Choose a reason for hiding this comment

torkleyy commented May 8, 2018

torkleyy commented May 8, 2018

torkleyy left a comment

Choose a reason for hiding this comment

AnneKitsune commented May 9, 2018 • edited Loading

Rhuagh commented May 9, 2018

Rhuagh commented May 9, 2018

Rhuagh commented May 10, 2018

AnneKitsune commented May 10, 2018

Xaeroxe left a comment

Choose a reason for hiding this comment

Xaeroxe commented May 14, 2018

Rhuagh commented May 14, 2018

bors bot commented May 14, 2018

Build failed

Rhuagh commented May 14, 2018

bors bot commented May 14, 2018

Build succeeded

Rhuagh commented May 1, 2018 •

edited by Xaeroxe

Loading

Xaeroxe commented May 3, 2018 •

edited

Loading

AnneKitsune commented May 4, 2018 •

edited

Loading

AnneKitsune commented May 9, 2018 •

edited

Loading