RE: [Isugamedev-midworld] Iteration 2

[Kevin M. <ke...@vr...>]

> > matter, we need to make sure the game (play) works.  
> 
> That was/is the goal of the first iteration. I'm trying to think ahead to 
> the next one ... where we do improvements to the prototype. Besides, I 
> want to make sure we get Andres heavily involved now to work out the art 
> issues. I know it takes much longer to update artwork than code. I'd 
> rather we hash through those issues early on.

ok, it just sounded like you were moving us to iteration #2 very soon, 
when iteration #1 is so far off from done (no game play yet).

> > theoretically it is nice, yes, but really for this prototype why is it 
> > needed?  in the end it isn't truely needed anyway as long as the user 
> > types slower than 70 fps (reasonable enough... :)
> 
> I may have put down the wrong name, but it's an input symbol library. 

so a .h file with lots of const ints ?  yay.  just copy what is in game 
kernel, it is already writen I think...

> So 
> that we can write all our apps for the same set of symbols for Keys and 
> Mouse inputs, etc. Then we don't have to have a different set for 
> GameKernel, phui, etc. I believe Chad already has this mostly written ...?

cool.  maybe port gamekernel to it.

> 
> As for GameKernel, I was also having problems with it relative to mouse 
> clicks. About 30% of the time, it misses my mouse clicks. I guess I click 
> to fast ... ;)

cool, add a task and it can be something to fix.  but i don't see how this 
keeps us from using game kernel in the prototype.  actually GK will save 
tons of dev time not reimplementing stuff...  as a framework it is 
completely good, it just needs improvment on the implementation.  Of 
course if you write anything from scratch, you'll have to do that PLUS 
make it catch every mouse click.   I'd rather do the fast option.  
especially for the proto.  I don't really understand the problem you have 
with GK i guess, you wrote it... :P   :)

> 
> > 
> > > * Basic UI (HUD for health, weapons, etc) implemented (with phui?)
> > >    - Depends on the input completion
> > 
> > why?  what user input are we getting?  you mention output only ideas, not 
> > anything with text input, and gamekernel is usable now.  not sure how this 
> > depends upon anything getting completed, it definately depends on phui or 
> > whatever widgets for health meters getting completed though...
> 
> The dependency is there since phui depends on the input symbol library.

ok, what about this...
> > why?  what user input are we getting?  you mention output only ideas, not 
> > anything with text input...

widgets for health meters isn't a phui thing I don't think...  Or does 
every widget have to be phui?  Why not just make a game object (c++ class) 
that can draw() itself.  and draw those to the screen?  I hate it that we 
might get swamped in frameworks and other crap when the solution is so 
simple and easy to do.  especially for a ___prototype___.  to me, that 
word makes me think "keep it very simple while showing the game's 
intent"... 



kevin

> 
> cheers,
> -----
> Ben Scott
> Research Assistant VRAC
> bs...@ia...
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
http://www.vrac.iastate.edu/~kevn               \        / 
Virtual Reality Applications Center            \/  __    \/
Howe Hall, Iowa State University, Ames Iowa        \__     
                                            \_\