|
|
Post by Daniel Everland on Dec 18, 2015 23:56:45 GMT 1
Original Suggestion: link
Please post any and all feedback, good or bad!  |
|
|
|
Post by Jatsu on Dec 19, 2015 0:45:48 GMT 1
Thanks for developing a Counter Cube! I think it's really awesome that logic has seen so many updates recently. It's a cool system and helps makes our games more interactive. I can't wait to see more development in that area. (: Onto the feedback: I think the fact that this Counter has both a visual and logic aspect to it is great. This makes it much more intuitive for new players. By having it decrement to zero instead of stopping on a hidden variable is probably the most clever aspect of its design. Players who see this will instantly be able to tell how many more signals the Counter will need in order to activate. Moving onto its function, it's great that it has a reset option in it. It saves an extra logic box and lets it be more reusable. However, there is currently an issue with logic reset on the Counter's zero value: Counter Cube does not obey Logic Reset once Activated. This mainly prevents Counters from being used to simulate winning conditions safely. Regarding other functionality though, it also relies heavily on the creator's side to make sure the Counter works properly because signal blocking affects it. Since it doesn't decrement when it takes a unique signal, but rather when all inputs are turned off, this makes it challenging to develop signals that effectively change the Counter value. Nonetheless, using BerickCook's timer set up helps keep those signals short enough to prevent most overlaps. There's also a small but still noticeable z-fighting issue on the front of the Counter cube when viewing it from a distance. Lastly, I think that the maximum counter value could be increased to 99 without much harm or confusion. This mainly benefits higher variability in logic builds such as "timer counters" that visible display the amount of time a player has left or score counters that track players' score. Mainly, if the value was up to 99, it could be chained with other counters in such a way that it creates larger values to work with (if a creator wanted to do that). I think that's as far as I can go with this feedback. I like the functionality and visual of the Counter cube. It could be cool to see more variability with a higher maximum counter value and a fix for the current logic reset issue. Thanks again for releasing an awesome feature! |
|
|
|
Post by Daniel Everland on Dec 25, 2015 4:14:03 GMT 1
Just wanted to post an update, since I doubt I'll develop the counting cube any further. I just put in the last changes, which'll hopefully be released in a patch sometime soon next year. Moving onto its function, it's great that it has a reset option in it. It saves an extra logic box and lets it be more reusable. However, there is currently an issue with logic reset on the Counter's zero value: Counter Cube does not obey Logic Reset once Activated. This mainly prevents Counters from being used to simulate winning conditions safely. Fixed There's also a small but still noticeable z-fighting issue on the front of the Counter cube when viewing it from a distance. Fixed Lastly, I think that the maximum counter value could be increased to 99 without much harm or confusion. This mainly benefits higher variability in logic builds such as "timer counters" that visible display the amount of time a player has left or score counters that track players' score. Mainly, if the value was up to 99, it could be chained with other counters in such a way that it creates larger values to work with (if a creator wanted to do that). Good point. Fixed Regarding other functionality though, it also relies heavily on the creator's side to make sure the Counter works properly because signal blocking affects it. Since it doesn't decrement when it takes a unique signal, but rather when all inputs are turned off, this makes it challenging to develop signals that effectively change the Counter value. I was actually working on doing exactly what you said, but Christian made an excellent point. It would be counter productive since I'd be making an exception to how logic cubes work. There's a base system behind when inputs are being called, and if I wanted the functionality you describe, I would have to abandon it and write my own. This is a bad thing for two reasons. Firstly, it's confusing to the player. Every other logic cube requires a complete reset before another input is possible, so why does this work differently? We want things to make sense of a fundamental level, and then build outwards from there - it would be wrong for me to disband the base functionality of logic cubes because my vision of how this single cube should work differs. Secondly it makes the code base more complex. If we find an issue with the base logic system in the future, you'd have to patch it two places in order for my logic cube to remain unaffected. If we update the base logic functionality in the future you'd have to do it two places. If there's an issue with my code, which is discovered when I'm not longer associated with KoGaMa, someone else has to sit down and figure out how my specialized system works. To summarize, the base idea is solid, but in coding and game design terms it's a poor idea. |
|
|
|
Post by Jatsu on Dec 25, 2015 6:52:35 GMT 1
Thanks for taking time to follow up, reply, and fix the prominent issues! I'll have to do some testing again but from the sound of it, its a significant improvement and will make the feature more enjoyable to use!
Regarding the signal blocking "non-issue", I definitely understand the reasons for not changing the way input signals work. Honestly, I only include comments like those to reflect on the system as a whole. In my other feedback, I remember writing that it was unintuitive for beginners but unavoidable given the current system. It's also the main reason I offered the workaround using Berick's timer design to minimize signal blocking.
Thinking about it further, signal blocking in general is probably the most realistic way of implementing signal control, since in reality two spliced together wires do oscillate quickly before finding an equilibrium state. The ultimate goal, I think, for the logic system is to simulate real logic-level design (gates and stuff) and their connections (feedback looping *cough*), therefore signal blocking is an effective simulation of such real world application.
Rambling again... on mobile too. ._. Anyway, thanks for sharing insight on the development reasons behind not changing it. I like hearing about these things. (:
Thanks again for the counter and nice work! I really enjoy having more logic toys to play with. :P
|
|
_Peruu_
Expert
EU Profile: http://www.kogama.com/profile/1152683/
Posts: 92 
|
Post by _Peruu_ on Dec 26, 2015 18:39:09 GMT 1
|
|
