Post by pinilla on Mar 15, 2017 2:57:25 GMT
First off, let me say thanks for making this guide. I've tried so many Unity guides, but always felt like every guide I was using was just hacking things together. It felt refreshing seeing some popular design patterns being used.
Coincidentally, I just decided to buckle down and give a game idea I've had a solid try. Luckily, your guide was there and I'm using your final product as a base. When I'm a millionaire...I'll give credit where it's due.
My basic idea is this. Instead of simply selecting an ability, I'm going to make my players "perform" the ability through the minigame. The outcome of the minigame will decide the ability's effectiveness (higher score, more power). I'm hoping that at least I have this part right - I want to insert a state after ConfirmAbilityTargetState to display the minigame.
I build an AbilityGame state and a corresponding AbilityGameController. The AbilityGameController will load the appropriate AbilityGame component from the turn.ability. The AbilityGame will house all the game data and will have start/end/display functions that can be called from the controller. I can't really build a UI prefab for everything (like we did with AbilityMenuController), because every game will have a slightly different UI. This to me means that I'll have to dynamically generate the UI in each AbilityGame's "display" method.
It doesn't seem right to me that I'd have a controller for each AbilityGame (although maybe it is), but it seems I'll just be forwarding everything from the State -> Controller -> AbilityGame through some select set of limited functions. This has already happened since the best way to share inputs between games is to forward them that way. Most of your other input logic is housed in the state currently, which I don't think will work for me without forwarding. The more I type, the more I realize I probably do need a controller for each game lol. Which I'm fine with, but should all those be loaded into the scene every time?
So that's one question. The second question is this. We've built a gameboard of 3d tiles that are all their own object. Let's say my most basic minigame is one like a top down 2d platformer, like the 2D top down unity tutorial. In that tutorial, they're using 3d physics to move the character, but I don't really feel like that's necessary. I like the simplicity of the grid system you've built with points. If my game is 8x8, do I just generate 64 MORE objects on the UI each with it's own "point" system like the tiles we've created? That seems wasteful when all I want to do is have a sprite moving through other sprites.
Sorry for the wall of text. You explain things in a way I very easily understand so I'm giddy at the prospect of a reply lol. Thanks.
Coincidentally, I just decided to buckle down and give a game idea I've had a solid try. Luckily, your guide was there and I'm using your final product as a base. When I'm a millionaire...I'll give credit where it's due.
My basic idea is this. Instead of simply selecting an ability, I'm going to make my players "perform" the ability through the minigame. The outcome of the minigame will decide the ability's effectiveness (higher score, more power). I'm hoping that at least I have this part right - I want to insert a state after ConfirmAbilityTargetState to display the minigame.
I build an AbilityGame state and a corresponding AbilityGameController. The AbilityGameController will load the appropriate AbilityGame component from the turn.ability. The AbilityGame will house all the game data and will have start/end/display functions that can be called from the controller. I can't really build a UI prefab for everything (like we did with AbilityMenuController), because every game will have a slightly different UI. This to me means that I'll have to dynamically generate the UI in each AbilityGame's "display" method.
It doesn't seem right to me that I'd have a controller for each AbilityGame (although maybe it is), but it seems I'll just be forwarding everything from the State -> Controller -> AbilityGame through some select set of limited functions. This has already happened since the best way to share inputs between games is to forward them that way. Most of your other input logic is housed in the state currently, which I don't think will work for me without forwarding. The more I type, the more I realize I probably do need a controller for each game lol. Which I'm fine with, but should all those be loaded into the scene every time?
So that's one question. The second question is this. We've built a gameboard of 3d tiles that are all their own object. Let's say my most basic minigame is one like a top down 2d platformer, like the 2D top down unity tutorial. In that tutorial, they're using 3d physics to move the character, but I don't really feel like that's necessary. I like the simplicity of the grid system you've built with points. If my game is 8x8, do I just generate 64 MORE objects on the UI each with it's own "point" system like the tiles we've created? That seems wasteful when all I want to do is have a sprite moving through other sprites.
Sorry for the wall of text. You explain things in a way I very easily understand so I'm giddy at the prospect of a reply lol. Thanks.
I like your confidence, I hope you achieve your goals.