Yakoob on 12/3/2015 at 00:37
Congrats Henke, sign me up for the beta :)
Quote Posted by Pyrian
Hmm. I'm not a big fan of extra pass-through calls. I did some work upfront to make sure my various UI elements don't interfere with each other (in particular the main screen), but the basic collider mouse mechanic does that pretty well on its own - it will only trigger the collider closest to the camera (a rare case of using Z-pos in 2D). I'm actually
removing certain centralized functions as I go.
Yea "Centralized approach" isnt always the best but I was using DF-GUI which works completely different from the Unity GUI and renders to different camera so it didn't "block" the clicks sadly. I couldn't even check if a GUI was clicked because sometimes the clicked-on object would trigger before the GUI processed its click. And I didn't want to disable highlight if gui was showing since I did want to allow re-selecting a different unit even if action buttons were up for one. X_X
In a game with different input/game modes/layers (gui vs. pass-thru gui vs. first-person control vs. minigame etc.) I still haven't figured out a better way than handling input in a central GameLogic that dispatches it through the listener stack until one of them says "ok, handled!".
Quote:
Heh, I have a similar issue with my Active Defense mechanic. I can't dodge if I don't have that ability, I can't dodge if I'm in certain terrain (mud or water), I can't dodge if I've already dodged once this round, I can't dodge if I'm using a special ability that precludes dodging (like holding ground or flurry of blows), and every dang one of these conditions needs a separate flag.
Yup, exactly. The Unity tutorials are great for boxed-in demos but don't account for growing complexity.
Pyrian on 12/3/2015 at 01:16
Quote Posted by Yakoob
I couldn't even check if a GUI was clicked because sometimes the clicked-on object would trigger before the GUI processed its click.
Yeah, this sort of behavior drives me bonkers. Unity's update/event order isn't really editable (I mean, you CAN delete and then recreate all your objects in the order you want, which works, but c'mon), and I don't understand why not. Right now I'm driving my entire Update loop through a single object just so I can guarantee the order of operations. Which I suppose takes me out of contention to argue against centralization, lol.
Quote Posted by Yakoob
In a game with different input/game modes/layers (gui vs. pass-thru gui vs. first-person control vs. minigame etc.) I still haven't figured out a better way than handling input in a central GameLogic that dispatches it through the listener stack until one of them says "ok, handled!".
That's a pretty standard approach; I remember seeing it way back in Turbo Pascal. Seems all the more strange that Unity doesn't have any equivalent way to arrange event calls nor return a "handled" flag. ...I wonder how the Unreal engine does this...
I've messed around with some of the GUI stuff, and none of it seems to offer me anything better than sprites and text meshes with colliders. Crazy.
Rant of the day: Context. Players demand context-sensitive UIs. If my guy isn't carrying a shield, they don't want to have the extra block order showing. And if the guy has a shield, but it's not equipped, they want to be able to equip it for the first order and then use it for their second order, anyway. And then if they cancel the first order, a dependent second order has to go away. And... And... And... This is a lot of work! I wish I could just let them issue any dang orders they want, and have them just fail if they don't make any sense. (Heck, I'm
still letting people issue orders to dead units, lol. Not that they'll
act on them...)
Yakoob on 12/3/2015 at 02:20
Quote Posted by Pyrian
Yeah, this sort of behavior drives me bonkers. Unity's update/event order isn't really editable (I mean, you CAN delete and then recreate all your objects in the order you want, which works, but c'mon), and I don't understand why not.
You can move components up/down in the list which I assume would've change their update order, but apparently nope! Or at least it's very buggy.
There's also a Script Execution menu but dragging every one of your scripts and reordering it is a huge hassle.
Quote:
Right now I'm driving my entire Update loop through a single object just so I can guarantee the order of operations. Which I suppose takes me out of contention to argue against centralization, lol.
Err doesn't that basically mess up the whole multi-threading and co-routines stuff, tho?
Why did you have to do that?
Quote:
That's a pretty standard approach; I remember seeing it way back in Turbo Pascal. Seems all the more strange that Unity doesn't have any equivalent way to arrange event calls nor return a "handled" flag. ...I wonder how the Unreal engine does this...
Yea I'm also surprised Unity doesn't have a messaging system builtin since it usually is (arguably) the best way to keep all components/game system in sync in component-based and asynchronous environment (at least that's what the Prototype guys did). Well, there is a SendMessage function but it's so bare-bones its basically useless.
Quote:
Rant of the day: Context. Players demand context-sensitive UIs. If my guy isn't carrying a shield, they don't want to have the extra block order showing. And if the guy has a shield, but it's not equipped, they want to be able to equip it for the first order and then use it for their second order, anyway. And then if they cancel the first order, a dependent second order has to go away. And... And... And... This is a lot of work! I wish I could just let them issue any dang orders they want, and have them just fail if they don't make any sense. (Heck, I'm
still letting people issue orders to dead units, lol. Not that they'll
act on them...)
I don't know how complex your gameplay is, but could you just take the list of all possible actions, test which ones would actually succeed/be allowed and discard the ones that aren't usable? Then you can just put whatever actions are left in some quick toolbar, or bind the most important one to the context sensitive "Interact" key.
(This, btw, is another fine example why Unity's "just let objects do their own thing" approach is crappy)
Pyrian on 12/3/2015 at 04:16
Quote Posted by Yakoob
You can move components up/down in the list which I assume would've change their update order, but apparently nope!
"Nope" is correct, lol.
Quote Posted by Yakoob
Err doesn't that basically mess up the whole multi-threading and co-routines stuff, tho?
Quite possibly; and I'm doing some retardedly unoptimized things, but thus far Moore's law has insulated me.
Quote Posted by Yakoob
Why did you have to do that?
There's an awful lot of dependencies. The time step (not Unity's standard delta time) needs to be calculated before any units update. The round end needs to be resolved after all units update. All the players need to update their visibility maps before the enemies update (as the enemies count on those maps to decide whom they can see).
Quote Posted by Yakoob
I don't know how complex your gameplay is, but could you just take the list of all possible actions, test which ones would actually succeed/be allowed and discard the ones that aren't usable?
Simultaneous turns; you and your opponent(s) give each unit two orders each turn, and they're all resolved at once. I'm basically doing that, except that I'm grouping them by order type, since the tests are by type as well. This feeds into drop downs also sorted by type - but if there's only one currently available order for that type, then it's just a button instead. And then there's orders which might require another order before they'll be successful, so I'm automagically queuing the necessary pre-order (e.g. if you order a sword swing and don't have a sword out, the draw sword order automatically gets issued first). And then people can cancel orders which are obligatory for the next order, necessitating that I detect that occurrence and remove the now-invalid order, as well. And it's actually pretty much all done now (there'll be more special orders later, but that can wait), but it took me all day. :P
Quote Posted by Yakoob
(This, btw, is another fine example why Unity's "just let objects do their own thing" approach is crappy)
My current strategy is to have each type of UI object encapsulated in a handler that organizes them and contains most of the relevant code. So, there's a container for the enemy cards which figures out which ones are visible and where they go, and there's a container for each type of order button which displays and organizes them. Similarly, each unit's life, ammo, and defenses are sub-objects which do most of their own calculations and animations, handling their individual sets of objects.
Yakoob on 12/3/2015 at 21:46
Quote Posted by Pyrian
"Nope" is correct, lol.
The annoying thing is I'm pretty sure I read somewhere in the docu that the order is
supposed to influence execution. I wonder if its just something that broke over the versions or if my memory is failing me.
A lot of criticism I hear against unity is that the team is more focused on adding shiny new features that get forgotten with time, rather than improving what is already there or bugfixing. I think I may be starting to see that.
Quote:
Quite possibly; and I'm doing some retardedly unoptimized things, but thus far Moore's law has insulated me.
Lol don't worry. In Postmortem each wall tile is actually a separate physics box. "I'll batch them into a single mesh later, grumble grumble." Turns out I never even had to do later since the game world is so small (thank god) :joke:
Quote:
There's an awful lot of dependencies. The time step (not Unity's standard delta time) needs to be calculated before any units update. The round end needs to be resolved after all units update. All the players need to update their visibility maps before the enemies update (as the enemies count on those maps to decide whom they can see).
Oh I was going to say this shouldn't be too bad until I remember the turns are simultaneous, so you do need to ensure that certain objects Update() before others.
In my code I use custom base monobehavior with its own Start/Update functions to ensure they dont get called at inappropriate times (i.e. wait until everything is loaded, or unpaused) but I dont think that would work for you.
I wonder if Unity's SendMessage() is multi-threaded or still operates on one thread? I think that's how current Start/Update/OnDestroyed etc. functions are called but I'm not sure.
Quote:
actions ... snip... And it's actually pretty much all done now (there'll be more special orders later, but that can wait), but it took me all day. :P
Ah gotcha, so you basically just compute all the possibilities (i.e. "draw sword + attack with sword") and just treat the pairs as one action on the list, then refresh the list each time an action is queued? Did i understand that right?
Renzatic on 13/3/2015 at 05:05
I'll say one thing. Sculpting chibi style super deformed characters and not making them look freaky as hell (
https://dl.dropboxusercontent.com/u/3018396/OMGOLOL.png) is hard to do.
I've spent at least 4 hours futzing around with that face just to keep it from looking better than half god-awful.
nicked on 13/3/2015 at 06:48
Quote Posted by Yakoob
I am liking the combo of edge detect + depth of field tho.
The edge detect makes everything look a lot better than earlier screenshots imo - the graphics now look more deliberately cartoony, and less unfinished in places. :thumb:
