"Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.14.1227086510.22690.digitalmars-d-announce@puremagic.com...
> On Wed, Nov 19, 2008 at 3:58 PM, Saaa <empty@needmail.com> wrote:
>>>> One last simple thing: In the Molly Rocket talk about immediate-mode
>>>> guis
>>>> a
>>>> comment is made
>>>> about some games not holding true to the convention that releasing the
>>>> mouse
>>>> away from the
>>>> clicked button will not result in button click.
>>>> ...
>>>> 3. faulty clicks are not that damaging
>>>
>>> Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_.
>>>
>>> It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)
>>
>> Well, I mentioned it as an indirect poll :)
>> So, you'd rather have the conventional buttons ingame?
>> And, which were the games in which the unconventional way was actually
>> frustrating you?
>
> I strongly disagree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI".   UI principles are universal.  It doesn't suddenly become ok to throw UI principles out the window because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it.   And, really, gamers are some of the most sensitive people in the world when it comes to UI.  Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy?
>
> --bb

I strongly agree with the notion that good usability principles in
a "game UI" somehow differ from usability principles that apply to
"regular UI".   UI principles are not universal. It doesn't suddenly
become ok to not think about UI priciples because the interface
happens to be used for shooting little digital green space aliens.
It's still an interface, and a human still has to use it.   And,
really, gamers are some of the most sensitive people in the world when
it comes to UI.  Ever heard gamers griping about how the graphics of
some game are nice but they threw it in the dustbin after a day
because the controls are too sloppy?
:)
Seriously,
I just asked whether you'd always want that kind of button behaviour
or that some situations (like certain games for instance) require a
different principle. I said that speed might be a reason to do this.
I think you vote no :)

-- Saa

On Wed, Nov 19, 2008 at 7:10 PM, Saaa <empty@needmail.com> wrote:
>
> "Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.14.1227086510.22690.digitalmars-d-announce@puremagic.com...
>> On Wed, Nov 19, 2008 at 3:58 PM, Saaa <empty@needmail.com> wrote:
>>>>> One last simple thing: In the Molly Rocket talk about immediate-mode
>>>>> guis
>>>>> a
>>>>> comment is made
>>>>> about some games not holding true to the convention that releasing the
>>>>> mouse
>>>>> away from the
>>>>> clicked button will not result in button click.
>>>>> ...
>>>>> 3. faulty clicks are not that damaging
>>>>
>>>> Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_.
>>>>
>>>> It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)
>>>
>>> Well, I mentioned it as an indirect poll :)
>>> So, you'd rather have the conventional buttons ingame?
>>> And, which were the games in which the unconventional way was actually
>>> frustrating you?
>>
>> I strongly disagree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI".   UI principles are universal.  It doesn't suddenly become ok to throw UI principles out the window because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it.   And, really, gamers are some of the most sensitive people in the world when it comes to UI.  Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy?
>>
>> --bb
>
> I strongly agree with the notion that good usability principles in
> a "game UI" somehow differ from usability principles that apply to
> "regular UI".   UI principles are not universal. It doesn't suddenly
> become ok to not think about UI priciples because the interface
> happens to be used for shooting little digital green space aliens.
> It's still an interface, and a human still has to use it.   And,
> really, gamers are some of the most sensitive people in the world when
> it comes to UI.  Ever heard gamers griping about how the graphics of
> some game are nice but they threw it in the dustbin after a day
> because the controls are too sloppy?
> :)
> Seriously,
> I just asked whether you'd always want that kind of button behaviour
> or that some situations (like certain games for instance) require a
> different principle. I said that speed might be a reason to do this.
> I think you vote no :)

Uh, yeh.  You guessed right.  I vote no.   :-)

--bb

Are you going to freak out if I tell you about my plan to have a few buttons
behave like the following:
if you click on one of them it is possible to select more of them by not
releasing your button and moving over them.
Or should I just not call them buttons anymore ? :D

>
> Uh, yeh.  You guessed right.  I vote no.   :-)
>
> --bb

Jarrett Billingsley escribió:
> On Tue, Nov 18, 2008 at 11:32 PM, Saaa <empty@needmail.com> wrote:
>> One last simple thing: In the Molly Rocket talk about immediate-mode guis a
>> comment is made
>> about some games not holding true to the convention that releasing the mouse
>> away from the
>> clicked button will not result in button click.
>> ...
>> 3. faulty clicks are not that damaging
> 
> Oops, I just used my one-time super awesome buff trinket that I was
> saving for Kil'jaeden _when I was fighting a trash mob_.

Bah, you know you were going to save that super awesome buff trinket until the very last big boss. But you don't know which one is it, and then the game suddenly ends and you never used that super awesome buff trinket. Better is at least using it with a trash mob.

> Bah, you know you were going to save that super awesome buff trinket until the very last big boss. But you don't know which one is it, and then the game suddenly ends and you never used that super awesome buff trinket. Better is at least using it with a trash mob.

Yeah, don't let the consciousness regain power and undo that click by dragging away from the button!

On Wed, Nov 19, 2008 at 7:25 PM, Saaa <empty@needmail.com> wrote:
> Are you going to freak out if I tell you about my plan to have a few buttons
> behave like the following:
> if you click on one of them it is possible to select more of them by not
> releasing your button and moving over them.
> Or should I just not call them buttons anymore ? :D

Sounds ok as long as you give them give them a different appearance from normal buttons.

About the original comment, it sounded to me like you were going to change the behavior just because it was a pain to program the "normal" way, and then you were rationalizing that it was ok because it's just a game.  Sorry if I misinterpreted.  If you have an actual reason to think some behavior will make for a better user experience then great. Go for it.  I certainly don't mean to say that every UI has to act like standard WIMP to be usable.  But if you're going to deviate for from the norm there should be a good reason to.  I do agree that games are an interesting place to experiment with alternative UIs since people don't necessarily expect them to look and feel just like Windows.  Whereas if you start getting creative with the UI in, say, a data entry app, users will probably want to throw things at you.

--bb

Bill Baxter wrote:
> Excellent talk!  Now I finally understand what the buzz about DDL is about.
> My vague understanding was that it was basically a workaround for
> current D compilers support of dynamic libs.  So I was content to just
> wait for D to get the kinks worked out eventually. But from your talk
> it seems much more like DDL is a better long term solution for dynamic
> linking of D code regardless.

Thanks! DDL is indeed something more :) In case of Windows, the issue is actually with DLLs, so no matter how awesome D's support of these gets, they still won't provide all that DDL can. I'm not yet sure to what extent SO could be abused to do what DDL does, but it would probably need some crazy runtime- and kernel-level programming skillz ;)
Anyway, I believe that this is just the beginning of what DDL might be able to provide. Once it matures, we'll probably see more cool stuff done with it - perhaps having the same code/plugin run on multiple OSes as long as the processor architecture is the same?


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Christopher Wright wrote:
> Peter Modzelewski wrote:
>> I believe DDL is a project I don't need to introduce. Tom gave a great talk about it and his branch of the project showing the power of DDL and D. Video can be found here: http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-ddl-talk.html 
> 
> 
> That looks like it has amazing implications for runtime reflection, even if you aren't using dynamic libraries. (I'd prefer it if the language and runtime supported runtime reflection, but DDL should be a lot better than nothing.)

True. Eric wrote some ramblings about it a few whiles ago: http://www.dsource.org/projects/ddl/wiki/DevNotes/Reflection

Another cool idea: http://www.dsource.org/projects/ddl/wiki/DevNotes/HLA


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Robert Fraser wrote:
> Peter Modzelewski wrote:
>> I believe DDL is a project I don't need to introduce. Tom gave a great talk about it and his branch of the project showing the power of DDL and D. Video can be found here: http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-ddl-talk.html 
>>
>> slides: http://team0xf.com/conference/DDL.pdf
> 
> The one I was most looking forward to... and it definitely didn't dissapoint. Runtime recompilation/reloading? CRAZY!

Hehehe thanks, I actually think it's crazy too :D In case you haven't seen it, my Nucleus/Nucled project uses this system on a wider scale. A smallish demo can be seen in http://vimeo.com/2164813 starting at about 35:12


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Saaa wrote:
> That is some amazing game dev framework!
> How is everything licensed?

Thanks! MIT/BSD. There are licenses in a few spots, but we were too lazy to add them everywhere :P


> For instance, I started out with loads of global variables and like almost no knowledge
> about oop and now I better understand modules and oop, things get nicely packaged and
> the global variable list is slinking.

Cool :) I hope you haven't exchanged them for singletons, which are for the most part excuses for having globals and pretending not to have them :P I usually shoot these on sight (unless they are justified) or replace them with thread-local stuff. This said, a few spots in the 'xf' stuff uses singletons, mostly because we didn't have the time/will to refactor them out ;)


> Everything I made can not do much beyond what it should be doing (opposite the teamh0xf framework)
> but that is what you get from being a one man show and try to focus half of my attention to
> AI research :D

Oh, sweet! Perhaps we'll have someone to bug about AI for Deadlock when something is working again ;)


> Why Cg? I used Cg for a bit but went back to GLSL because of its simplicity.

* access to the hot and latest NVidia extensions
* easy porting to DirectX ... just in case
* CgFX
* NVidia tools
* some support for pre-shader NVidia hardware, like the GeForce3


> One last simple thing: In the Molly Rocket talk about immediate-mode guis a comment is made
> about some games not holding true to the convention that releasing the mouse away from the
> clicked button will not result in button click.
> I think that in-game guis should not hold to this convention because of three things:
> 1. it is faster and holding to the convention could become quit annoying
> 2. highlighting the hot buttons is more elaborate in games (well most of the times of course)
> 3. faulty clicks are not that damaging 

Depends ;P I'd take an adaptive approach. Start with the 'normal' behavior, release it to testers and ask if they felt that any particular widgets/types of buttons should have a different behavior. Then just subclass the Button widget and be done with it.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode