Issue 28: Menue Design
Project Member Reported by srpli...@gmail.com, Apr 16, 2010
We need to work out some new designs for the menu's. This will bring will
allow us to come up with a feel for the entire games interface.
Apr 16, 2010
Project Member #1 srpli...@gmail.com
(No comment was entered for this change.)
Owner: Lift_...@yahoo.com
Apr 19, 2010
Project Member #2 Techerci...@gmail.com
Different style ideas: 
-LFO HUD style
-Scub vision style
-Gekko HUD style
-High Altitude theme
-Nature theme
-LFO Laboratory theme

That's all I've got for now.
Apr 24, 2010
Project Member #3 srpli...@gmail.com
I will come up with something this weekend Cerebrate.
May 10, 2010
Project Member #4 srpli...@gmail.com
ughhhh such a busy month!!! i made this las night. its got the very basic feel..there
no bells and wistels know what i mean? like i didnt do any font selections or color n
what not...dunno wanna add alot more to it when i get time. the basic idea is lfo
selection screen, you scroll left and right till u get the one you want, click on it-
it slides to the left the others disappear , and you get a bio screen with info on
the mech and then you can go back or buy the lfo. we all sucked this month! sleepy,
spelling bad..


Menues2 copy.jpg
526 KB   View   Download
Menues copy.jpg
598 KB   View   Download
May 10, 2010
Project Member #5 srpli...@gmail.com
(No comment was entered for this change.)
Labels: -Milestone-May Milestone-June
May 10, 2010
Project Member #6 Techerci...@gmail.com
I'd rather the pictures be in-game renders in the final version. It would aid
immersion and would help us display LFOs that aren't in the anime (starter LFO, anyone?).
May 10, 2010
Project Member #7 roboj...@gmail.com
The only problem is I can't change lfo's on the fly in game cause of how my code
works.  So this menu will need to be in the main menu where you currently choose it.
May 10, 2010
Project Member #8 srpli...@gmail.com
This is a bit of a problem, that pretty much cuts out the whole purchasing new LFOs
part of the game, is there anything you can do about it?
May 10, 2010
Project Member #10 Techerci...@gmail.com
Yeah, hide the options in the menu until they're purchased, which is an in-game
activity. You could RP it as taking your LFO back to the garage to switch it out/pick
up your new one.

May 10, 2010
Project Member #11 srpli...@gmail.com
while thats a step in the right direction, best case scenario would be able to buy
and select your LFO without leaving a server/
May 10, 2010
Project Member #12 roboj...@gmail.com
the code does something like this:

Player is connected to server
Player object is instantiated
LFO model is instantiated based upon their preference
Preference value is sent to everyone over the network, and is stored in the buffer 
for any players that connect after this player (so their model is correct).

And this is the kicker where changing it gets hard:
Upon model instantiation (for both the player and how you appear to other players), 
the code finds various "transforms" (game objects) in the model and uses those as 
reference points for mounting the board and guns.  This code is not only executed on 
the player that just connected, but everyone else.

Then guns and boards are instantiated and connected to their various found attachment 
points.

If one deletes the lfo model (or eureka for that matter), the code starts throwing a 
hissy fit, because then it starts to attempt to find said bone in the model to keep 
things attached!  Also the animation code will take a dump as it attempts to keep 
updating the main model that has now just disappeared.

Synchronization is also an issue.  Because now you've got to fill up your network 
buffer with even more shit of you changing your model.  And changing your model would 
cause everyone each to need to change said model, and make sure they do it smoothly 
(all while having to deal with instantiations coming over the network from you, 
slightly delayed, attempting to spawn from things that don't currently exist)

Basically: I could, but it would require a serious code revamp, possibly requiring me 
to rewrite not only the character instantiation, but a bunch of logic dealing with 
board/weapons over the network. And a lot of planning time to make it work well and 
avoid the network buffer issues.

May 10, 2010
Project Member #13 Torchl...@gmail.com
in the end, i think that all that stuff your saying should be revamped, like you said
it would need to be. i think it would be a better result down the track, as atm, it
will either not be possible to do certain things, or to do them would break the
flow/immersion of the game.

also, i have an idea for the lfo selection screen, where they would be drawn
artwork(either taken from the anime or drawn by one of us or something) but when you
select it( before you go into the bio screen) that image would fade away and have a
real time model of the lfo there, doing say an idle animation or something(standing
still, or on a board flying towards you(without actually moving closer. this would
also look cooler)

now, i know this is all POSSIBLE, but will prob require alot of work on cer's
part(this is why we should have more than 1 programmer, perhaps we could recruit
some1 who has experience with unity or something?)
May 11, 2010
Project Member #14 srpli...@gmail.com
I agree with torchling. This is a huge problem that if we try to work around it will
greatly effect our final product. It may sound like asking alot, but its something
that simply has to be done. 

On the selection screen idea, that was something I was thinking about as well, but i
decided against it in the end.
May 11, 2010
Project Member #15 Torchl...@gmail.com
any particular reason as to why?

i think we should have the realtime model of the lfo on the bio screen at least then.
slowly turning or something like that just to show it off a bit. as you don't really
get to see the lfo's(other than your own) all that much, at least not very close up
anyway. would be nice to have it on the selection screen
May 11, 2010
Project Member #16 Techerci...@gmail.com
I agree with using a model instead of art in the LFO screen for reasons already
mentioned.

I guess it would be a pain to have to repeatedly leave and rejoin the server in order
to switch around your LFOs. Couldn't a special exception or instance be coded that
would instruct the server to not attach those objects to the bones, or order said
objects to simply remain at their last coordinates in space until the exception ends
and the new LFO is in?
May 11, 2010
Project Member #17 srpli...@gmail.com
I think i decided against it because it sounded like alot of work torch. I never
really got cerebrates input on it tho. I love the idea tho.
May 11, 2010
Project Member #18 roboj...@gmail.com
(No comment was entered for this change.)
Blockedon: 32
Nov 8, 2010
Project Member #19 roboj...@gmail.com
relates to issue 55.
Status: Accepted
Labels: -Milestone-June Milestone-Release1.0 Component-UI Priority-Critical
Blockedon: -32