General UI

[Daniel Zwolenski]

Our UI is obviously very crude at the moment as it should be, but as I started to put in the Tower placement stuff I found some areas it might be better to clean up now.

HUD Overlay

Currently, the general style of the UI we are using is a BorderPane where the GameControlPanel is docked to the right. Having played around with Bloons I really like their Head Up Display (HUD) style approach where all the controls are overlayed over the Level. 

This will work much better on a small screen (mobile, tablet, pi, whatever) but I think it also looks better in general (I recommend trying out Bloons TD on your mobile if you get the chance) and is more game-like. 

proposal #1: overlay game controls on main scene: make SimpleGameScene internally use a StackPane instead of a BorderPane. Add the LevelPanel to the bottom of the stack. Add the GameControlPanel to the top of the stack (probably in an an AnchorPane with pickOnBounds set to false).

SimpleGameScene vs Game

In most places we haven't separated View from Model from Control, e.g. LevelPanel is the level model, the level view and the level control; Enemy is MVC all in one; Tower, Projectile; etc. 

Then at the top level we suddenly have Game (MC) and SimpleGameScene (V). It's a bit odd and pattern wise which one do we reference, where. We pass around a reference to the Game, but what if I want to show something in the SimpleGameScene (like a dialog to start a new Game). Should the Game have a reference to the Scene and we trigger displays indirectly or should we pass around references to the SimpleGameScene, etc?  

I feel like we should either separate out everything into MVC or at least into V vs M+C (or we should merge SimpleGameScene and Game into one? I could be convinced of the split (?) but the latter is the current dominant approach we have and easiest would be to stick with it. 

proposal #2: merge Game and SimpleGameScene into one class called Game. At the same time rename LevelPanel to Level to be more consistent with Game/Enemy/Tower/Wave/Projectile.

FXML Best Practices

I also struggled with the FXML that has been generated from SceneBuilder. The GridPane thing is not a real dynamic approach and all the funny constraints make it hard to edit by hand. Maybe using SB it would be ok, but as soon as we start adding in dynamic elements that link in with code I'd tend to start working with the FXML directly (maybe I'm just old school though?).  

I'd actually suggest that FXML is not really helping us for the HUD as it is pretty specific and we should just code up this part of the UI in Java. If we do want the FXML then the way we are using it is not all that great. It's strange to load it and embed it like is done now and then look up elements by ID. The "controller" concept exists to avoid all that. 

If we stick with FXML, I'd expect not to have a GameControlPanel and instead have a GameControlControlller (at which point the names need reconsidering) that is referenced by the GameControl FXML. It would be then be the SimpleGameScene that does the FXML load and then passes the "Game" object to the controller and adds the fxml loaded view to the scene.    

(As an aside to Richard, your attempt to use FXML to basically "make a self defined view" is one of the patterns I pushed for early and making the FXML just bind to an arbitrary class passed in, instead of the whole fxml-creates-the-controller concept would have allowed for this and much more. Greg wasn't strongly against it though. The cludgy controller injection that was added helps, but still hasn't made it overly convenient to do this pattern and many others). 

So proposal #3 would be to either just code up the game control elements in Java or switch to use the Controller way of dong things. If switching, I'd also be keen to rewrite the FXML to be clean and simple since the generated stuff is pretty nasty and I like to work with it by hand for dynamic elements. 

Dialogs and Screen Flow

I like the way Bloons does it's dialogs - basically a floating Node that pops up as an overlay over the rest of the screen (exactly what I did for dialogs in jfxflow). These also tend to animate in/out. I'd be keen to replicate this and if we're gong to 

So proposal #4 include a "dialog" layer in Game. Add methods to Game (aka SimpleGameScene) that allow showing of the dialogs and general workflow of screens (i.e. choose level, choose difficulty, game over, etc).  

Zooming and Panning

I kind of like the idea that our level should be zoomable and possibly pannable. Either this would be manually controlled by the user or it would be more just a case of the level being scaled to the size of the screen. If we're thinking about small screen devices then this seems pretty necessary. 

If we're going to do zooming and panning then it might be easiest to do a bit of this work up front as things like Tower placement coordinates, etc, will likely change when zoom changes. 

This one is more a question than a proposal. What do you guys think about this? Should we zoom, and if so how to do it cleanly? Can we just use the inbuilt FX scale and translate to do zooming and panning? I've had some feedback on this sort of stuff from my forum post on it but I need to dig through what the guys have given me for more details. 

I'm probably thinking that next coding chance I get, I'll look at implementing the above proposals before doing anything more on Tower placement. Let me know thoughts when you have a chance - I might get a little bit of coding time tomorrow night my time but can hold off if you need more time to review. 

[Richard Bair]

HUD Overlay

Currently, the general style of the UI we are using is a BorderPane where the GameControlPanel is docked to the right. Having played around with Bloons I really like their Head Up Display (HUD) style approach where all the controls are overlayed over the Level. 

This will work much better on a small screen (mobile, tablet, pi, whatever) but I think it also looks better in general (I recommend trying out Bloons TD on your mobile if you get the chance) and is more game-like. 

proposal #1: overlay game controls on main scene: make SimpleGameScene internally use a StackPane instead of a BorderPane. Add the LevelPanel to the bottom of the stack. Add the GameControlPanel to the top of the stack (probably in an an AnchorPane with pickOnBounds set to false).

I'll have to run it to see. I don't really have an opinion on this one.

SimpleGameScene vs Game

In most places we haven't separated View from Model from Control, e.g. LevelPanel is the level model, the level view and the level control; Enemy is MVC all in one; Tower, Projectile; etc. 

Then at the top level we suddenly have Game (MC) and SimpleGameScene (V). It's a bit odd and pattern wise which one do we reference, where. We pass around a reference to the Game, but what if I want to show something in the SimpleGameScene (like a dialog to start a new Game). Should the Game have a reference to the Scene and we trigger displays indirectly or should we pass around references to the SimpleGameScene, etc?  

I feel like we should either separate out everything into MVC or at least into V vs M+C (or we should merge SimpleGameScene and Game into one? I could be convinced of the split (?) but the latter is the current dominant approach we have and easiest would be to stick with it. 

proposal #2: merge Game and SimpleGameScene into one class called Game. At the same time rename LevelPanel to Level to be more consistent with Game/Enemy/Tower/Wave/Projectile.

I'd stick with the "autonomous view" for now. We can break it apart a little later if we find that there is value in separating them. I started off with model/view separation, but it was just a lot of noise in the implementation that ended up being tons simpler when it was combined. Basically the realization I had was that in the case of a graphical app like a game, the SceneGraph *was* the model. Otherwise things like x, y, etc have to be properties on the model and bound to the view. Can be done, and maybe should be done, but at this point it seems simplest just to have an autonomous view.

FXML Best Practices

I also struggled with the FXML that has been generated from SceneBuilder. The GridPane thing is not a real dynamic approach and all the funny constraints make it hard to edit by hand. Maybe using SB it would be ok, but as soon as we start adding in dynamic elements that link in with code I'd tend to start working with the FXML directly (maybe I'm just old school though?).  

I'd actually suggest that FXML is not really helping us for the HUD as it is pretty specific and we should just code up this part of the UI in Java. If we do want the FXML then the way we are using it is not all that great. It's strange to load it and embed it like is done now and then look up elements by ID. The "controller" concept exists to avoid all that. 

I don't know, it seems the same to me. Whether I have FXML doing auto-inject into @FXML annotations or I use lookup to pull out specially named things -- the coupling between the two sides is the same.

So proposal #3 would be to either just code up the game control elements in Java or switch to use the Controller way of dong things. If switching, I'd also be keen to rewrite the FXML to be clean and simple since the generated stuff is pretty nasty and I like to work with it by hand for dynamic elements. 

In which way is it nasty? One of the design goals for SceneBuilder was that the XML it generates must be as nice has hand-edited. If it is failing to live up to that, we need to know how so we can fix it, because the design goal remains the same. I know from experience with GUI builders (NB, others) in the past that if the format worked on by the tool is not the same as 'hand crafted' then on development teams the tool will have trouble because some engineers will hand edit and other use the tool and the two will have a war at some point.

Dialogs and Screen Flow

I like the way Bloons does it's dialogs - basically a floating Node that pops up as an overlay over the rest of the screen (exactly what I did for dialogs in jfxflow). These also tend to animate in/out. I'd be keen to replicate this and if we're gong to 

So proposal #4 include a "dialog" layer in Game. Add methods to Game (aka SimpleGameScene) that allow showing of the dialogs and general workflow of screens (i.e. choose level, choose difficulty, game over, etc).  

I believe these are called "LightBoxes". I would like a reusable LightBox control, actually, in JavaFX.

Zooming and Panning

I kind of like the idea that our level should be zoomable and possibly pannable. Either this would be manually controlled by the user or it would be more just a case of the level being scaled to the size of the screen. If we're thinking about small screen devices then this seems pretty necessary. 

If we're going to do zooming and panning then it might be easiest to do a bit of this work up front as things like Tower placement coordinates, etc, will likely change when zoom changes. 

This one is more a question than a proposal. What do you guys think about this? Should we zoom, and if so how to do it cleanly? Can we just use the inbuilt FX scale and translate to do zooming and panning? I've had some feedback on this sort of stuff from my forum post on it but I need to dig through what the guys have given me for more details. 

I would avoid zooming and panning for now. Most (every?) of this genre I've played didn't have zooming / panning, so I think we should get a full functional version up and running with a fixed game board size first.

Richard

[Daniel Zwolenski]

I have pushed some new code to my fork (pull request has been updated) that adds: 

• A welcome screen (ugly) that includes some text transitions - i.e. a kind of animated splash screen - needs a designer to do something cool here
  
• A "lightbox" dialog for starting a new game that animates in (dialog flies in/out, glasspane fades in/out)

On a code level:

• SimpleGameView is gone - some of it went into DefenderApp, some went into Game
  
• .ui. package added with several view classes (e.g. WelcomePane, NewGamePane)
  
• FXML usage is based on Controllers and all FXML was hand written and stripped to minimum 

I stuck with not separating out the view-model-controllers. Agree that MVC split would be cumbersome in a graphically-heavy app like this (does feel a bit dirty though, sometimes in a good way). I left zooming and panning alone (would like to see some sort of resizing eventually, at a minimum for "responsive" layout for different screen sizes), and I didn't overlay the HUD (think it would be good to do but low priority). 

We have our first performance problems!

Terminology check, for me "Performance" = anything where the user will say "gee, that's a bit slow/lame". I don't know if it's rendering or what.

Most of the transitions are a little bit jerky:

• The first entry text is really bad, it stutters and jerks - possibly to do with the the font, size colour or some other css aspect?
• The next fade in is a bit better but the last step it seems to change from thick to thin (maybe from/to anti-aliased or something). Very noticeable.  
• The spinning, fading growing text seems to be the best but maybe that's just cause there's so much happening you can't notice problems. 
• The opening of the orange background to reveal the game view seems to stutter just at the last second before it finishes. 
• The dialog fly/fade in looks generally ok - not sure why as it's a relatively similar transition

It's definitely not smooth and slick at any rate on my Dell Latitude (Win7 64bit, Intel Core i7-2620M 2.7GHz, 4GB RAM). It could be my code but as far as I know I'm following the recommended approaches for what I'm doing. 

Busy time... the deployment packaging code just got released today (woohoo!!). As much as I would prefer to be working on this game than working on dull deployment aspects I think the other is probably more important. Not sure I've got capacity to do both after hours (got a big paid project due in Feb as well before I go travelling so its starting to spill into 'hobby' time). I may be going quiet on this project for a little while. Why is the fun stuff always the one the one that gets bumped for everything else? 

[Daniel Zwolenski]

The orange background stuttering was my code I think (math calculation was off) - checked in a fix. The rest of the problems still stand.